📋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.
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:
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.
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.
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.
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:
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.
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.
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.