> 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/native-automation-screens/decision-and-approval-work-queues.md).

# 📥 Decision and approval work queues

## Decision and approval work queues

### Decision and approval work queues

#### Decision and approval work queues

**Decision and approval work queues**

Use this page when you are building an approval review experience. In the builder, the actual native screen names are Decision and Work Queue.

![Decision screen type.](https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FaqLbH5XFz43EB7jYCpbk%2Fautomation-screen-decision-builder-20260705.png?alt=media\&token=70e8a8ee-525e-4d63-bda7-f39a8b99b6c9)

*Use Decision when one reviewer opens one item and chooses an outcome.*

![Work Queue screen type.](https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2F5nB1Ti9ZiYZNqMNf7vU3%2Fautomation-screen-work-queue-builder-20260705.png?alt=media\&token=cbd20caa-6f43-4ebe-89eb-757015916060)

*Use Work Queue when a team needs a list of approval items or operational work.*

**When to use Decision**

Use Decision when the reviewer needs a focused screen for one item. A Decision screen should show the fields needed to decide and the actions the reviewer can take.

Common decision actions:

* Approve
* Reject
* Request changes
* Escalate
* Acknowledge
* Complete review

**When to use Work Queue**

Use Work Queue when a person or team needs to manage many items. A Work Queue should help users sort, claim, assign, prioritize, and complete work.

Use Work Queue for:

* Supervisor review queues
* Finance review queues
* Purchasing queues
* Service dispatch queues
* Exception triage queues
* Any approval team that handles a list instead of one item at a time

**Exact build order**

Use this order when the maker is creating an approval experience for the first time:

1. Create the normal requester screen first. This is usually a data form or submit screen.
2. Create or generate the approval workflow from Automation.
3. Add the **Work Queue** Automation screen if reviewers need an inbox.
4. Add the **Decision** Automation screen so the reviewer has approve, reject, and request-changes actions.
5. Bind the Work Queue and Decision screens to the same approval workflow.
6. Set visibility so reviewers can see the Work Queue and Decision screens.
7. Hide those reviewer screens from requesters unless the app intentionally exposes them.
8. Submit a test request as the requester.
9. Open the Work Queue as the reviewer.
10. Open the request and decide it on the Decision screen.
11. Confirm the source record updates and the requester sees the result.

Do not wait until after testing to add the Decision screen. The Decision screen is where the approval actually becomes usable for the reviewer.

**Recommended approval setup**

1. The requester submits from the source data page.
2. The workflow creates a review task or routed item.
3. The reviewer receives a message or notification.
4. The item appears on Decision for the reviewer.
5. If a team owns the work, the item also appears in Work Queue.
6. The reviewer approves, rejects, or requests changes.
7. The workflow updates the source record status.
8. The requester sees the result on the source record or Workflow Status.
9. Any missing reviewer, permission issue, or failed message appears in Exception Resolution.

**What to show on the screen**

A reviewer should see business context:

* Request title
* Requester
* Amount or priority
* Reason
* Due date
* Department or category
* Attachments or supporting details if the app has them
* Current status
* Decision history or notes

Do not make reviewers decode internal workflow IDs.

**Verification**

A Decision or Work Queue approval setup is ready when a newly submitted request appears for the reviewer role, can be opened, shows enough context, supports the expected decision action, updates the source record, and leaves no unexplained exception.