Approval Workflows
Canonical maker page for approval outcomes and the shared inbox item types. The first-approval how-to stays short and links here. Decision / Work Queue screen behavior stays in the Types of Screens guides.
What this is / when to use it
Section titled “What this is / when to use it”Use Approvals when a human must record a decision that the workflow will read.
When not to: a status dropdown that anyone may flip. That is a data screen.
Before you start
Section titled “Before you start”Approval Management entitlement is on. You have a request form and a Decision (or Work Queue) screen for the approver. Wizard: Create your first approval workflow.
Build it
Section titled “Build it”- Run the approval wizard, or attach an approval step to
form_submitted. - Bind the Decision screen (or Work Queue with Review) for the approver role.
- Enable the outcomes you actually need (table below). Do not enable all nine “because they exist.”
- Test: submit as requester → item appears in the inbox → decide → requester sees Workflow Status or a notification.
Every control
Section titled “Every control”Outcomes (ApprovalDecisionValue)
Section titled “Outcomes (ApprovalDecisionValue)”| Outcome | Enum | Meaning | Typical next step |
|---|---|---|---|
| Approved | approved |
Yes | Change status, continue route |
| Rejected | rejected |
No | Notify requester, end |
| Changes requested | changes_requested |
Send back | Requester edits, resubmits |
| Need more information | need_more_information |
Blocked on a question | Conversation or waiting status |
| Delegated | delegated |
Another approver | Reassign |
| Escalated | escalated |
Higher role | New assignment |
| Held | held |
Pause | Wait |
| Cancelled | cancelled |
Withdrawn | End |
| Custom | custom |
Your label | Your branch |
Assignment statuses (ApprovalAssignmentStatus): open, claimed, completed, cancelled, expired, reassigned, released.
Topics that resume the workflow
Section titled “Topics that resume the workflow”A Decision card is created when a workflow Publish Message uses a request topic such as client.review.requested (item type decision). The workflow then Wait for message on the reply topics. Those names must match what the Decision outcome publishes:
| Outcome | Reply topic the Wait must list |
|---|---|
| Approved | client.decision.approve |
| Changes requested | client.decision.changes_requested |
| Rejected | client.decision.reject |
The builder’s Use all client decision topics writes that set. A homemade topic never wakes a Wait that lists the presets. Full catalog: Topics that perform work.
Shared inbox model
Section titled “Shared inbox model”| Item type | Enum | Screen |
|---|---|---|
| Task | task |
Work Queue |
| Decision | decision |
Decision |
| Message | message |
Conversation |
| Exception | exception |
Exception Resolution |
| Notification | notification |
Notification Center |
| Linked app request | linked_app_request |
Linked App Exchange |
| Launch | launch |
Automation Launcher |
Item statuses include open, claimed, waiting, completed, cancelled, expired, failed, resolved, acknowledged, dismissed. Claim means ownership. Waiting means the item is paused on someone else or on a message. Expired means the due/SLA window passed.
What users see
Section titled “What users see”Approvers see Decision (or Work Queue Review). Requesters see Workflow Status and notifications. They do not pick enum names; they tap the buttons you enabled.
Limits and plans
Section titled “Limits and plans”Approval Management is its own entitlement (enabled + capability toggles). Messaging + Workflow are separate. A Decision screen without entitlement is an empty inbox.
Example
Section titled “Example”Purchase > $5k: outcomes Approved, Rejected, Need more information, Escalated. Need more information opens Conversation. Escalated assigns the manager role. Held is off — they use Escalated instead.
Fix problems
Section titled “Fix problems”Decision and Queue Troubleshooting. Empty inbox: wrong role, draft automation, or screen visibility.