Work Management
Approvals
Configure and operate approval flows across tasks, documents, and workflow approval nodes.
Approvals
Approvals covers The decision layer used by tasks, documents, booking policies, and workflow Approval nodes. Use this page when you are configuring the live product surface, planning a rollout, or checking why users see different data from what an administrator sees.
What this surface is
- Primary purpose: The decision layer used by tasks, documents, booking policies, and workflow Approval nodes.
- Where staff start: Users review assigned approvals from
/approvals/list; task-specific approval views also appear under/tasks/approvals. - Where admins configure it: Builders configure approval steps inside the feature that owns the request, such as a workflow, document flow, or task process.
- Runtime/detail surface: Approvals show requester, approver, status, comments, timestamps, and the item being approved.
- Platform connections: Approval outcomes can continue a workflow path, update records, notify users, or stop a process.
Common workflows
| Workflow | What happens | Where to check |
|---|---|---|
| Identify the | Identify the object being approved and the decision that must be recorded | Confirm in the product route above before publishing. |
| Choose approvers | Choose approvers by role, team, manager, specific user, or workflow data where the product surface allows it | Confirm in the product route above before publishing. |
| Define whether | Define whether one approval is enough or whether sequential approval is required | Confirm in the product route above before publishing. |
| Write clear | Write clear request titles and context fields so approvers can decide without leaving the page | Confirm in the product route above before publishing. |
Configure it
- Identify the object being approved and the decision that must be recorded.
- Choose approvers by role, team, manager, specific user, or workflow data where the product surface allows it.
- Define whether one approval is enough or whether sequential approval is required.
- Write clear request titles and context fields so approvers can decide without leaving the page.
- Configure rejection handling: return to requester, stop the process, reopen a task, or route to another path.
- Test approve and reject paths with real permission boundaries, not only as a superadmin.
- Add notifications for approvers and requesters where response time matters.
- Review approval history before changing live approval rules.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Task approval | Operational work needs sign-off | Appears in task and approval lists. |
| Workflow Approval node | A visual process needs a decision gate | Configure in Workflow Studio. |
| Document approval | A file, registry entry, or template requires review | Owned by the Documents module. |
| Booking approval | A booking policy requires human confirmation | Owned by Bookings settings. |
| Sequential approval | Finance, HR, or compliance needs a chain | Keep each step accountable. |
| Rejection path | The requester must correct data | Add comments and reroute deliberately. |
Operating notes
- Approval pages are only useful when approvers can see enough context to decide.
- Avoid hidden approval chains; show users who owns the next decision when possible.
- Escalation rules should be agreed before the process goes live.
- When approvals are created by automation, log the source workflow and record ID.
- Use comments for decision rationale, not for structured values that reports need.
- If an approval is stuck, check assignee, role filters, notification delivery, and workflow job logs.
- Keep approval names specific: “Expense over threshold” is better than “Manager approval”.
- Do not reuse one approval flow for unrelated policies just because the approver is the same.
- Test rejection just as carefully as approval; failed rejection paths create operational dead ends.
- Review pending approvals during offboarding so requests do not remain assigned to inactive users.
For developers
Use the developer and reference pages when this configuration is read or changed by code, scripts, widgets, embeds, API clients, or webhooks.
- /developer/overview
- /developer/quickstart-api
- /reference/jql-overview
- /reference/namespaces
- /developer/outbound-webhooks