> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/automation/approval-workflows.md).

# 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

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

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](https://docs.notionapps.com/automation/create-your-first-approval-workflow).

## Build it

1. Run the approval wizard, or attach an approval step to `form_submitted`.
2. Bind the Decision screen (or Work Queue with Review) for the approver role.
3. Enable the outcomes you actually need (table below). Do not enable all nine “because they exist.”
4. Test: submit as requester → item appears in the inbox → decide → requester sees Workflow Status or a notification.

## Every control

### 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

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](https://docs.notionapps.com/automation/messaging-and-notifications#topics-that-perform-work).

### 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

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

Approval Management is its own entitlement (enabled + capability toggles). Messaging + Workflow are separate. A Decision screen without entitlement is an empty inbox.

## 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

[Decision and Queue Troubleshooting](https://docs.notionapps.com/automation/troubleshooting-automation/decision-and-queue-troubleshooting). Empty inbox: wrong role, draft automation, or screen visibility.

## Related

[Decision screen](https://docs.notionapps.com/screens-and-components/types-of-screens/native-automation-and-operational-screen-guides/decision-screen). [Work Queue](https://docs.notionapps.com/screens-and-components/types-of-screens/native-automation-and-operational-screen-guides/work-queue-screen). [Which automation](https://docs.notionapps.com/automation/which-automation).