> 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/customize-app/types-of-screens/automation-screens/work-queue.md). # Work Queue ## Work Queue Screen > Current state: this native screen is part of **Automation (Beta Testing)**. It is entitlement-gated, uses NotionApps runtime state instead of ordinary Notion data controls, and should be tested with realistic workflow or messaging activity before a maker relies on it in production. The **Work Queue** screen gives users a focused inbox for automation-created work. It can show tasks, reviews, follow-up items, assignments, approval-adjacent work, and exceptions that need a person to take ownership. Think of this screen as **a shared or personal work inbox powered by Workflow and Messaging**. It should help the right person understand what is happening and what they can safely do next without reading raw JSON, copying internal IDs, or opening backend logs. ### Who This Guide Is For This guide is for makers configuring a **Work Queue** screen in the app builder. It explains the purpose of the screen, what users see after publication, what each builder section means, and how to avoid confusing or unsafe setups. Use this guide when: * You are building a task inbox created by workflow routes. * Users need to claim, complete, release, or escalate work. * A team needs one place to manage human follow-up created by automation. * You are deciding whether work belongs in a queue, decision screen, conversation, or normal data screen. ### What The Screen Is For Use Work Queue when automation creates work that a person must handle. The queue item is not simply a Notion row. It is a runtime object that can carry status, ownership, due date, workflow run reference, conversation reference, correlation reference, payload summary, and action state. Good examples: * A support team claims incoming follow-up requests. * A supervisor queue shows records that need manual review before the workflow continues. * An operations team receives tasks generated by a webhook intake workflow. * A service desk manages items that can be completed or escalated. * A role-based team inbox shows work assigned to Technicians, Managers, or Admins. Bad examples: * A normal list of Notion records that users browse without automation ownership. Use a data screen. * A single approval question with Approve and Reject outcomes. Use Decision. * A chat thread or clarification exchange. Use Conversation. * A high-level health dashboard. Use Operator Console. * A read-only status timeline. Use Workflow Status. ### The Mental Model A **Work Queue** screen has three layers. | Layer | What it means | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | | Builder configuration | The maker chooses the source, access rules, display rules, actions, preview state, and empty copy. | | Automation runtime state | NotionApps creates or receives workflow, messaging, queue, notification, exchange, or operator state that belongs to the screen. | | Live user experience | A user opens the app, sees only the allowed state, and either reviews it, acts on it, or uses it as context. | The key idea is: ``` A Work Queue item is a unit of human work created by automation, not a database row with a prettier layout. ``` ### What Users See In The Live App In the live app, users see the screen title, description, last updated time, queue guidance, and a **Current work** section. Each item appears as a card with status, summary, optional due date, safe details, support references when expanded, and action buttons. A live **Work Queue** screen can show: * Open work item title and status. * Plain-language summary and due date. * Review details from payload summary when payload preview is enabled. * Support details hidden behind a toggle for technical references. * Claim or Release button depending on current ownership. * Complete button to finish the work item. * Escalate button when the work needs higher-level review. * Timeline entries when timeline display is enabled. Claiming should be treated as ownership. Completing should be treated as a workflow signal. Escalating should be treated as an exception or handoff signal. If the user only needs to view a record, do not put that record in Work Queue. ### Required Foundations And Entitlements Work Queue normally depends on Workflow Foundation because workflows usually create, claim, complete, and escalate queue items. Messaging Foundation is useful when message routes create queue items or when queue work is tied to a conversation. | Requirement | Why it matters | | -------------------------------------- | --------------------------------------------------------------------------------------- | | Automation screen entitlement | The screen appears in the Automation group and must be allowed for the app/account. | | Workflow Foundation | Queue items normally come from workflow runs and need action handling. | | Messaging Foundation, optional | Required when messages create queue items or queue items need conversation context. | | Private app/user database, recommended | Role-based queues usually need a user database so visibility can target teams or users. | ### Builder Configuration Sections The builder page for every native automation screen has the same major sections. The controls are shared, but the meaning changes depending on the screen type. Read the section notes below before publishing the screen, because most configuration mistakes come from choosing a broad listen scope, exposing too much payload detail, or giving the wrong users action access. #### Header And Screen Type The top of the configuration panel identifies the screen as a **Native app screen** and shows the saved screen type. This matters because native automation screens do not read Notion rows directly. They read NotionApps runtime state: workflow runs, queue items, decisions, messages, notifications, exceptions, linked app exchanges, and operator summaries. The title and description shown here are the same words users see in the live app unless the screen is using a template preview state. For **Work Queue**, the maker should name the screen for the user job, not for the internal system. Use names like **My Work**, **Team Queue**, **Open Reviews**, **Follow Up Work**. Avoid names that expose implementation details such as workflow IDs, route IDs, channel names, or support references. #### Automation Source Automation source is the most important section. It decides which runtime events this screen listens to. If the source is too broad, users may see unrelated work. If it is too narrow, the screen may look empty even though automation is running. For Work Queue, the source decides which work items are eligible to appear. A broad source creates a team inbox. A narrow source creates a process-specific inbox. | Listen scope | How to use it for Work Queue | | ------------------------------ | --------------------------------------------------------------------------------- | | Entire app | Use for an owner/team inbox that collects work across multiple workflows. | | Specific screen or form | Use when work is created from one form, such as submitted requests. | | Specific workflow | Use when this queue belongs to one process, such as onboarding or service triage. | | Conversation or message thread | Use when queue items are created from a channel/topic or tied to a conversation. | | Linked application | Use rarely, when app-to-app exchanges create work items for this queue. | Makers should normally start with the narrowest scope that still matches the business job. Use **Entire app** for owner dashboards and shared team inboxes. Use **Specific workflow**, **Specific screen or form**, **Conversation or message thread**, or **Linked application** when the screen belongs to one process. #### Template Setup State This section reports whether a managed template or demo provisioning run remapped this screen correctly. If the screen came from a cloned app, provisioning should connect the cloned screen to the cloned workflows, channels, topics, linked apps, and generated objects. A healthy screen usually shows **Provisioned**. **Needs review** means the app may still open, but the screen should not be trusted until the binding is checked or Automation Home repair is run. **No setup report** is normal for apps that were built manually rather than cloned from a template. For **Work Queue**, review this section after cloning a template, repairing a demo, changing a workflow, renaming a messaging channel, or replacing a form. The screen may still exist visually after those changes, but it can become pointed at old runtime objects unless provisioning remaps it. #### Related Context Related context is the builder's sanity check. It summarizes how many screens/forms, controls, workflows, and messaging channels are available to the screen picker. Hidden screens can appear here on purpose. A workflow may route a user to a hidden screen, or a native screen may listen to a hidden form that is not shown in navigation. Deleted screens should not be selected. For this screen, related context is especially useful for: * Confirming the form that creates the queue item is selectable. * Finding the workflow that owns the queue. * Checking whether the message channel/topic that creates work exists. * Selecting after-action screens without memorizing screen IDs. #### Visibility And Access Visibility and access uses the same visibility model as normal data screens when the app is private and has a user database. That means makers can use user-record fields such as role, team, department, email, or plan to decide who sees the screen. The advanced allow lists are tighter controls: allowed role names limits access to matching role values, and allowed users limits access to specific emails or saved user references. For operational screens, prefer explicit roles such as Admin, Supervisor, Operations, or Support instead of broad end-user access. Recommended access for **Work Queue**: * Shared team queues: allow the team role and any fallback admins. * Personal queues: combine user visibility rules with workflow assignment rules. * Customer-facing apps: only expose queue items when the customer is expected to act. * Internal operations queues: restrict to Supervisor, Operations, Support, or Admin roles. #### Display And Action Policy This section controls the words, density, payload exposure, timeline visibility, and claim policy. It is where a maker turns a technical automation surface into a usable live app screen. | Setting | What it means for Work Queue | Recommended default | | --------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------- | | Screen title | Names the inbox users are working from. | Team Queue or My Work | | Description | Explains which work appears and what users should do with it. | Claim one item, review the details, then complete or escalate it. | | Payload visibility | Controls whether users can inspect item details and support references. | Redacted preview | | Density | Controls how tightly item cards are displayed. | Comfortable for low volume; compact for high volume. | | Show timeline | Shows item changes, workflow steps, and audit activity. | On for operators; optional for simple end users. | | Require claim before action | Controls whether users must own an item before acting. | On for shared queues. | Payload visibility has three levels: | Level | Meaning | When to use it | | ---------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Metadata only | Shows status, title, timestamps, and safe runtime metadata without record details. | Use for broad audiences, customer-facing status, and screens where the payload contains private data. | | Redacted preview | Shows selected safe details and hides sensitive or technical fields. | Use for most operational and human-work screens. | | Full payload | Shows the fullest runtime payload available to the screen. | Use only for trusted internal operators or support-style screens. | #### Available Actions Available actions are the commands users can run from the live screen. Some screens are read-only. Others can claim work, complete work, submit decisions, reply to a conversation, acknowledge notifications, dismiss notices, escalate, or launch a workflow. Actions can optionally route the user to another screen afterward, and some actions can target a workflow. | Action | Runtime action type | What it does | | -------- | ------------------- | -------------------------------------------------------------------- | | Claim | `claim` | Assigns the item to the current user or marks ownership. | | Complete | `complete` | Signals that the human work is finished. | | Release | `release` | Appears for claimed items so ownership can be returned to the queue. | | Escalate | `escalate` | Routes the item to a higher-level workflow or exception path. | For shared queues, require claim before completion whenever two users could touch the same item. Configure after-action screens when completing a task should send the user to a status page, detail record, or conversation. #### Preview Scenario Preview scenario is for builder validation, screenshots, and automated tests. It does not force live users into fake data. Use it to inspect desktop, tablet, and mobile layouts; portrait and landscape; requester, technician, supervisor, operator, and admin personas; and runtime states such as empty, loading, error, waiting approval, claimed by me, claimed by another user, overdue, or conversation active. For **Work Queue**, preview these states before publishing: * Empty, to confirm the queue does not look broken before work exists. * Waiting approval, to show an unclaimed item. * Claimed by me, to verify release and complete behavior. * Claimed by another user, to confirm locked ownership copy. * Overdue, to verify urgency and escalation copy. * Mobile portrait, to confirm action buttons stay reachable. #### Empty State And Sample Data Empty state and sample data controls what users see when no matching runtime state exists. A good empty state tells the user whether they are finished, waiting for someone else, or missing setup. Sample item, sample workflow run, and sample conversation are builder-only references used to preview a known object before production traffic exists. Good empty-state copy for **Work Queue** should answer: * Is there truly no work, or is setup missing? * Should the user wait, refresh, or contact someone? * Does the copy reassure the user that the queue is healthy? ### Common Configuration Patterns Work Queue is flexible, so the safest pattern is to decide whether the queue is team-wide, process-specific, or person-specific before configuring it. #### Shared Team Inbox A group of internal users handles work as it arrives. Recommended configuration: * Listen scope: Entire app or Specific workflow. * Visibility: team role only. * Require claim before action: on. * Payload visibility: redacted preview. * Timeline: on for accountability. #### Form Review Queue A form submission creates work for reviewers. Recommended configuration: * Listen scope: Specific screen or form. * Source screen/form: the submitted form. * After-action screen: record detail or workflow status. * Empty copy: no submissions need review. #### Escalation Queue Only overdue or failed work should appear. Recommended configuration: * Listen scope: Specific workflow. * Access: Supervisor/Admin. * Payload visibility: redacted preview or full payload for trusted operators. * Action target workflow: escalation workflow. ### Testing Checklist Before publishing or handing this screen to a customer, test the following. * [ ] Create a queue item from the intended workflow or message route. * [ ] Verify the correct role can see the item. * [ ] Verify an unrelated user cannot see the item. * [ ] Claim the item as one user and verify another user sees ownership correctly. * [ ] Complete the item and confirm the workflow or route continues. * [ ] Escalate the item and confirm the target path receives context. * [ ] Check mobile layout with long titles and payload fields. * [ ] Confirm empty state appears after all work is completed. ### Troubleshooting #### The queue is empty even though work exists What it usually means: The source binding or visibility rules are probably too narrow. What to check: * Confirm listen scope. * Confirm selected workflow/screen/channel still exists. * Confirm the queue item is assigned to the current user or role. * Check whether template provisioning says Needs review. #### Users see unrelated work What it usually means: The source binding is probably too broad. What to check: * Switch from Entire app to Specific workflow or Specific form. * Add role visibility rules. * Confirm workflow assignment payload is correct. #### Two users completed the same work What it usually means: The queue did not require ownership before action or backend action handling allowed duplicate completion. What to check: * Enable require claim before action. * Test claimed-by-other state. * Confirm workflow action is idempotent. ### Best Practices * Use Work Queue for work ownership, not ordinary browsing. * Keep queue titles action-oriented. * Use redacted payload previews by default. * Require claim before action for shared teams. * Route completed users to the most helpful next screen. * Keep support references collapsed unless a user needs diagnostics. ### Recommended Default Setup Use this as a safe first configuration when the maker is unsure. * Listen scope: Specific workflow. * Visibility: Supervisor or Operations role. * Payload visibility: Redacted preview. * Show timeline: on. * Require claim before action: on. * Empty title: No work is waiting. * Preview state: waiting approval, then claimed by me, then empty.