Task Approvals
By default, anyone who is an Owner or Assignee of a task can mark it as complete themselves. But for some tasks — especially regulated, contractual, or high-stakes ones — you want a second set of eyes before the task is closed. That's what Task Approvals are for.
When approval is required, the assignee submits a Completion Request instead of marking the task directly complete. Designated approvers are notified, review the submission, and either approve or reject it. Only after approval does the task move to "Completed."
When to use task approvals
Not every task needs an approval. Use it when:
- Completion must be verified by someone else — for example, a fire safety inspection can't be self-certified. The project manager or a compliance officer needs to confirm it's done.
- A senior sign-off is required — budget sign-offs, legal clearances, brand approvals.
- Multiple parties must agree — when both the General Manager and the Finance Director need to confirm a task is complete before it counts.
- Audit trail is important — the approval creates a timestamped record of who confirmed what and when, which is valuable for compliance and handover documentation.
Enabling approvals on a task
There are two ways to turn on approval requirements:
1. In the Task Catalog Item (applies to all projects)
When you're building or editing a Task Catalog Item, enable Task Completion Requires Approval in the item's settings. Every task generated from this catalog item — across all projects — will require approval before it can be completed.
This is the recommended approach for tasks where approval is always required, regardless of which project it's on.
See Task Catalog Items for the full configuration options.
2. On an individual project task (applies to this task only)
Open a task and go to the Settings tab. You can enable the approval requirement here for this specific task, even if the catalog item didn't have it set. Conversely, if the catalog item had approval enabled, you can also adjust the approvers on a per-task basis.
Choosing approvers
You can designate approvers in three ways:
Specific person — name a particular user directly. They are always the approver for this task, regardless of which project it's on. The most straightforward option and the most reliable.
Dynamic (project field) — point to a user field on the Project Blueprint. Whoever is filled into that field on the project becomes the approver. For example, if the blueprint has a "Quality Assurance Manager" field, set that as the dynamic approver. Every project automatically routes the approval to the right person without any manual setup. This is the recommended approach for catalog items.
By project role — assign the approval to a role label (the same labels used in "Assign to Roles", e.g., "Finance Director" or "Restaurant Manager"). This is a two-step process:
- In the catalog item, you set the approver as "By Role: Restaurant Manager." This is a placeholder — it just says someone in that role should approve this.
- On the project, when you use the Assign by Role action in the task dashboard to assign a person to the "Restaurant Manager" role, Compass automatically connects that person as the approver for every task configured with that role. From that point on, they receive approval requests normally.
Think of it as a template: the catalog says "whoever is Restaurant Manager should approve this." The project setup fills in the actual name.
| Situation | What happens |
|---|---|
| Role configured, no one assigned to that role yet | Falls back to the task's Owners as approvers |
| Role configured, person assigned via Assign by Role | That person receives the approval request |
| No approvers and no owners | Submitting a completion request will fail |
If a task has only role-based approvers and the role hasn't been assigned to a real person yet, approval requests fall back to the task's Owners. If there are no owners either, the task cannot be completed at all. Make sure to run Assign by Role as part of your project setup. For critical tasks, prefer a specific person or a dynamic project field as the approver — these are resolved automatically and don't depend on a manual step.
You can mix all three approaches — for example, always require sign-off from a named compliance officer, plus whoever is assigned as Restaurant Manager on this specific project.
Approval modes: Any vs. All
When there are multiple approvers, you choose how many approvals are needed:
| Mode | What it means |
|---|---|
| Any | One approval from any of the listed approvers is enough. The first person to approve closes the request. |
| All | Every listed approver must approve. The task stays in "Awaiting Approval" until all of them have responded. |
Use Any when the approvers are peers and any one of them can confirm the work — for example, any one of three regional managers can sign off.
Use All when the task requires agreement from multiple stakeholders before it's truly done — for example, both the General Manager and the Director of Finance must approve a significant pre-opening expenditure task.
The approval workflow
Here's what happens step by step when a task has approval enabled:
Step 1: Assignee submits a Completion Request
When the assignee believes the task is done, they click Submit for Completion instead of marking it complete directly. They can add a note explaining what was done, attaching any relevant context for the approvers.
The task status changes to Awaiting Approval.
Step 2: Approvers are notified
All designated approvers receive a notification (email and in-app) that a completion request is waiting for their review. The notification includes the task name, the submitted notes, and a direct link to the task.
Step 3: Approver reviews and decides
Each approver opens the task and reviews the completion request. They can:
- Approve — confirm the task is complete. They can add an optional note explaining their decision.
- Reject — decline the completion. They should add a note explaining what's missing or what needs to be corrected.
Step 4: Outcome
If approved (either by one approver in "Any" mode, or all approvers in "All" mode):
- The task moves to Completed
- A timestamped record of who approved and when is saved in the Task History
If rejected (by any approver):
- The completion request is closed
- The task goes back to its previous open status (typically In Progress or Re-Opened)
- The assignee is notified with the rejection reason
- They can address the feedback and submit a new Completion Request when ready
Seeing approvals in context
For assignees: A task you've submitted will show the Awaiting Approval status in the task list. You can open the task to see the current state of each individual approver's decision (pending, approved, or rejected).
For approvers: Tasks waiting for your approval appear in your task list with the "Awaiting Approval" status — filter by this status to find everything that needs your sign-off. You can also set up a personal dashboard widget to surface these quickly.
Audit trail: Every approval, rejection, and submission is recorded in the Task History tab with the exact timestamp and the name of the person who took the action. This record is permanent and cannot be edited.
Quick reference
| Scenario | What to do |
|---|---|
| Always require approval for a task type | Enable in the Task Catalog Item |
| Require approval for one specific task | Enable in the task's Settings tab |
| One approver from a pool is enough | Set Approval Mode to "Any" |
| All stakeholders must sign off | Set Approval Mode to "All" |
| Approval should go to the project's QA Manager | Use a dynamic approver pointing to the QA Manager project field |
| Completion request was rejected | Check the Task History for the reason, address the feedback, and resubmit |