📋Work Queue Screen
Current state: this native screen is part of Automation. 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 is a focused inbox for tasks, approvals, exceptions, and follow-up work that needs a person to claim and finish.
Think of this screen as A shared desk of work items that people claim, complete, or escalate.
Who This Guide Is For
This guide is for makers configuring a Work Queue screen in the app builder. It lists every builder option available on the screen and explains how to use each one.
Use this guide when:
A team needs an inbox of workflow-created work.
Users must claim ownership before completing an item.
Operators need one place for mixed human work (tasks, follow-ups, some decisions).
What The Screen Is For
Use Work Queue when
A team needs an inbox of workflow-created work.
Users must claim ownership before completing an item.
Operators need one place for mixed human work (tasks, follow-ups, some decisions).
Do not use it when
A single approve/reject checkpoint — use Decision.
Free-form discussion — use Conversation.
Operational health dashboards — use Operator Console or Workflow Status.
What Users See In The Live App
Active / History / All segments (Active default).
Work cards with title, status, summary, and ownership.
Claim, Complete, and optional Release when claim is required.
Review modal for Submission / Documents / Overview when Submission review is configured.
Default listen scope
Entire app
Require claim before action
Off
Default preview persona / state
Technician / Waiting approval
Empty title
No work is waiting
Empty description
New tasks and decisions appear here when workflows or messages need a person.
Required Foundations
Automation screen entitlement
Work Queue appears in the Automation / Operational group.
Workflow, optional Messaging
Primary foundation for this screen’s runtime state.
Private app + Users database (recommended)
Role/tenant visibility and audience policy need user fields.
Complete Builder Options Reference
The sections below match the builder order. Read them from top to bottom when you configure the screen: each option explains what the control changes in the live app, how to set it up in practice, and which default or mistake matters most for a queue that people actually use.
Header and screen type
This section tells the builder which native screen you are editing and gives the live screen its basic label. Makers often rush through it, but the title and description are what users rely on when they decide whether this queue is for them.
Screen type
What it does: Sets the native runtime behavior to Work Queue, which means the screen renders claimable work items instead of normal Notion rows. How to use it: Leave the screen type as Work Queue once you create the screen. If you need approvals, conversation threads, or read-only operations status, create the matching native screen instead of trying to repurpose this one. Why / recommended default: The screen type is the foundation for everything else in the panel. A common mistake is expecting ordinary list controls here; this screen is for automation runtime items only.
Category
What it does: Places the screen in the Automation or Operational family inside the builder so makers can find it again later. How to use it: Keep the existing category that the native screen ships with. Use navigation labels and grouping elsewhere in the app to decide where users discover the queue. Why / recommended default: This is mostly organizational, but it helps teams keep native screens separated from everyday data screens.
Title
What it does: Sets the end-user title shown in navigation and at the top of the live queue.
How to use it: Name the job, not the implementation. Good examples are Manager approvals, Ops follow-up, or Intake work queue. Avoid titles like workflow_17_queue or internal project names.
Why / recommended default: Clear titles reduce training and mis-clicks. If users cannot tell who owns the queue, they will either ignore it or open the wrong desk.
Description
What it does: Adds helper copy under the title so users know what they are expected to do on the screen. How to use it: Write one short sentence that tells people what belongs here and what action they should take, such as "Claim new intake tasks and complete follow-up work." Why / recommended default: A good description reduces hesitation, especially when you have multiple automation desks in one app. The common mistake is leaving a generic description that says nothing about ownership.
Automation source
This section decides which runtime items are allowed to appear in the queue. It is one of the most important sections because a Work Queue only feels trustworthy when users understand why an item showed up there and why something else did not.
Entire app
A shared operations queue covering many flows
Showing too much mixed work to one team
Specific screen or form
Queues that start from one intake surface
Forgetting to update the binding after replacing the form
Specific workflow
A focused queue for one process
Pointing at the wrong published workflow version
Conversation or message thread
Message-driven follow-up work
Expecting it to behave like a general chat screen
Linked application
Cross-app handoff work
Using it when no linked app route exists
Listen scope
What it does: Chooses the top-level source of work items the queue listens to. How to use it: Start with Specific workflow when the queue exists for one business process. Use Entire app only when you intentionally want a cross-process shared desk. Choose Specific screen or form when one intake form is the natural boundary. Why / recommended default: The safest default for most maker-built queues is Specific workflow, not Entire app, because it keeps the desk understandable. A common mistake is leaving the queue too broad and then wondering why unrelated work keeps appearing.
Source screen or form
What it does: Appears when the listen scope is Specific screen or form and binds the queue to that intake surface. How to use it: Pick the form or screen that creates the work. After cloning or replacing a form, revisit this picker and confirm it still points at the new source. Why / recommended default: This is useful when teams think in terms of one intake experience rather than one workflow. The most common mistake is assuming the builder will automatically follow a renamed or swapped form.
Workflow
What it does: Appears when the listen scope is Specific workflow and filters the queue to items created by that workflow. How to use it: Select the published workflow users should work from. If the workflow has sibling versions for staging or demos, double-check that you picked the production one. Why / recommended default: This is the recommended default for a focused team queue. It keeps visibility understandable and makes troubleshooting much easier when a task does not appear.
Messaging channel
What it does: Narrows message-driven queue activity to one messaging channel. How to use it: Set this only when your queue is fed by messaging routes or conversation-linked work. Match the channel name used by the workflow or route that emits the item. Why / recommended default: Channel filtering is powerful, but it is also easy to misconfigure. If the screen looks empty, a channel mismatch is one of the first things to check.
Topic
What it does: Narrows the source further to one topic within the selected channel, such as approval.requested or another stable route label.
How to use it: Use the exact topic the route publishes. Keep topic naming consistent across automations so makers can reason about filters without reading backend details.
Why / recommended default: Topic filters are best when you want one queue per type of work. A common mistake is using slightly different topic strings between environments and creating "mysteriously empty" queues.
Conversation or correlation
What it does: Binds the queue to one specific thread or correlation context when the process is case-based. How to use it: Use this only when the queue should follow one ongoing case, request, or thread. Leave it broader for a shared team desk. Why / recommended default: Most Work Queue screens should not hard-code a single correlation. Over-filtering here can make a perfectly healthy queue look broken.
Linked application
What it does: Appears for linked-app listening and binds the queue to one external NotionApps application. How to use it: Pick the linked app only when work truly enters the queue from an app-to-app exchange. Otherwise leave the queue on workflow or form scope. Why / recommended default: This option is usually not the right starting point for Work Queue. Use it only when the work really originates outside the current app.
Include sheets
This screen-specific section lets makers limit the queue to work tied to selected Notion sheets. It is most helpful when one workflow touches several sheets but only some of them should surface in this desk.
Included sheets
What it does: Limits the queue to items associated with the checked sheets. If nothing is checked, the queue can show work from every eligible sheet in scope. How to use it: Check only the sheets that produce work for this specific team. For a true cross-sheet operations inbox, leave every sheet unchecked so the queue stays broad. Why / recommended default: Use sheet filters when teams own different parts of the data model. The common mistake is checking a sheet during testing and forgetting that the filter is still active in production.
App audience and notification prefs
These controls are app-level policy even though they appear on the screen config. Work Queue respects the same tenant boundaries and notification-category rules as the rest of the automation surfaces, so this section is where you keep the queue aligned with who should see shared work.
Tenant mode
What it does: Defines whether runtime items are broadcast broadly or partitioned by tenant relationship. How to use it: Choose Off only for simple single-tenant apps. Choose Relation when users should only see work for their own client, company, branch, or account. Why / recommended default: For most multi-user production apps, Relation is the safer default. Leaving tenant mode off in a multi-tenant queue is one of the highest-risk visibility mistakes a maker can make.
Tenant field
What it does: Identifies which relation field on the Users sheet tells the platform how to group users into tenants. How to use it: Pick the company, client, account, or workspace relation field from the Users sheet. Use the field that already powers other tenant-aware parts of the app. Why / recommended default: Consistency matters more than cleverness here. If you point the queue at a different tenant field than the rest of the app, users will see inconsistent visibility.
Role field
What it does: Tells the platform which Users-sheet field stores each person's role if it is not the default Role field.
How to use it: Leave it blank when your user role property is already named Role. Set it explicitly when your app uses a custom name such as Team Role or Access Level.
Why / recommended default: This is a small setting with big consequences. If the wrong field is chosen, your visibility rules can look correct in the builder while failing at runtime.
Notification categories
What it does: Maps category keys and labels to preference fields so users can opt into or out of notice types. How to use it: Add only the categories your automations truly send, then bind each one to the matching preference field on the Users sheet. Why / recommended default: Even though Work Queue is not a notification screen, these categories often shape how people discover follow-up work. Too many unused categories create policy clutter and confuse future makers.
Add notification category
What it does: Adds another category row, typically with in-app and email delivery defaults. How to use it: Create a new category only when you have a real sender and a real user preference to connect to it. Why / recommended default: Fewer, well-named categories are easier to govern. The common mistake is creating categories "just in case" and never wiring them consistently.
Save audience policy
What it does: Persists tenant and notification preference changes at the app level. How to use it: Click it after every tenant or category update before leaving the screen. If you are testing with several personas, save first and then retest. Why / recommended default: Unsaved audience policy is a classic source of false debugging. Makers often think the queue is wrong when the real issue is simply that the policy changes were never saved.
Template setup state
This section is diagnostic rather than interactive. It helps makers understand whether a template clone or repaired demo still has healthy automation bindings behind the queue.
Setup state indicator
What it does: Reports whether the automation screen setup looks provisioned, needs review, or has no setup report.
How to use it: Treat Provisioned as the happy path. Treat Needs review as a prompt to re-check your workflow, form, and channel bindings. Treat No setup report as normal for hand-built apps.
Why / recommended default: This indicator can save a lot of time after cloning a template. The common mistake is ignoring a Needs review badge and then troubleshooting the wrong layer for hours.
Related context
This section gives read-only discovery context so you can find the other objects that matter to the queue. It is especially useful in mature apps where builders may not remember which form, workflow, or follow-up screen was originally intended.
Related context panel
What it does: Shows discovery counts and related references for screens, forms, workflows, channels, and other nearby runtime objects. How to use it: Use the panel to jump to likely bindings, review what already exists, and locate candidate after-action screens or detail screens before creating duplicates. Why / recommended default: This panel reduces guesswork. The common mistake is copying raw IDs around when the builder already provides safer pickers and discovery cues.
Visibility and access
This section controls who can open the queue at all. A Work Queue often contains shared operational work, so visibility design matters as much as the source filter design.
Visibility rules
What it does: Applies the same visibility-condition model used by other private-app screens. How to use it: Build conditions around stable user fields such as role, team, location, or tenant membership. Keep the logic readable so another maker can audit it later. Why / recommended default: Role- and tenant-based rules are usually safer than broad access. A common mistake is making the queue visible to everyone and relying on source filters alone to keep people out of the wrong work.
Allowed role names
What it does: Adds a direct allow list of role names for this queue.
How to use it: Enter a concise CSV list such as Technician, Supervisor, Admin when a simple role gate is enough.
Why / recommended default: This is often the fastest reliable access control for team desks. The common mistake is adding too many near-duplicate role names and creating hidden access drift.
Allowed users
What it does: Allows individual people by email or user reference even if they are not part of the main role-based rule. How to use it: Use this for named operators, pilot users, or emergency backstops. Keep the list short and review it after launches. Why / recommended default: Per-user overrides are useful, but they do not scale well. The common mistake is quietly building the whole access model out of exceptions.
Submission review
This screen-specific section controls the in-place review modal that opens before a user completes work. It is the main way to let someone inspect the submission without navigating away from the queue.
Overview fields + full record
Governed review with quick summary plus full detail
Recommended default
Overview fields only
Short, structured queues where the important fields are obvious
Good for speed
Full record only (legacy)
Older setups that still rely on the full form view alone
Use only when needed
Review sheet
What it does: Defines which sheet powers the curated Overview field pickers. How to use it: Leave it blank to auto-detect from the source item when that works cleanly. Set it explicitly when the queue can receive mixed items and you want a stable review configuration. Why / recommended default: Auto-detect is convenient, but explicit binding is safer in more complex queues. The common mistake is pointing the review at the wrong sheet and then wondering why the field picker looks incomplete.
Review mode
What it does: Chooses whether reviewers see curated overview fields, the full submission, or both in the modal. How to use it: Pick Overview fields + full record for most governed work. Choose Overview fields only when the full record is noisy and you want a faster operational flow. Use Full record only mainly for compatibility with older setups. Why / recommended default: The recommended default is Overview fields + full record because it balances speed and confidence. A common mistake is offering only the full record, which makes simple work items harder to scan.
Overview fields
What it does: Defines the ordered shortlist of fields shown in the Overview tab. How to use it: Select the minimum set a user needs to decide whether to claim, complete, or escalate the work. Put the most decision-relevant fields first. Why / recommended default: A curated overview makes queues much more usable. The common mistake is checking every field and recreating the clutter of the full form.
Submission screen override
What it does: Replaces the automatically chosen full-record tab target with a specific screen. How to use it: Bind the exact details or update screen you want reviewers to open in the Submission tab. Leave it blank only when the auto-selected target already matches the real source experience. Why / recommended default: This is the safest way to make the modal predictable. A common mistake is assuming auto-selection will still be correct after screens are renamed or replaced.
Documents screen override
What it does: Binds the Documents tab in the review modal to a specific document or photo screen. How to use it: Point it at the related documents list or upload surface users actually need during review. Leave it blank when the automatic document target is already correct. Why / recommended default: This matters most in document-heavy queues. The common mistake is configuring Submission review but forgetting to wire the documents experience that operators rely on.
Inbox modes
These modes are what end users switch between in the live app, but makers should still understand them while configuring the screen because they affect testing, training, and expectations around where finished work goes.
Active, History, and All
What it does: Splits the queue into currently actionable items, past terminal items, and the combined full record. How to use it: Train users to work from Active by default, check History when they need proof an item was handled, and use All for audits or support investigations. Why / recommended default: The default live segment is Active because it keeps the desk focused. A common mistake is thinking a completed item disappeared when it actually moved to History.
Display and action policy
These controls shape how much context people see on each item and how the queue behaves when multiple people share it. For Work Queue, this section is where you tune the balance between speed, safety, and operational density.
Screen title override
What it does: Lets you override or refine the title shown in the live queue. How to use it: Use the end-user wording your team already uses day to day. If the queue is process-specific, include the process name rather than internal workflow terminology. Why / recommended default: Consistent language matters more than clever labels. If a user has to translate the title mentally, the queue will feel less reliable.
Description
What it does: Controls the helper copy shown under the title in the live view. How to use it: Tell users exactly what they should do here, for example "Claim open cases, review the submission, and complete work when finished." Why / recommended default: Specific instructions reduce mistakes for infrequent users. The common mistake is leaving a vague description that sounds like every other operations screen.
Payload visibility
What it does: Chooses how much of the runtime payload the queue reveals. How to use it: Use Metadata only for broad or external audiences, Redacted preview for most internal team queues, and Full payload only for trusted operators who genuinely need raw detail. Why / recommended default: Redacted preview is the usual default for Work Queue because it gives people enough context without oversharing. Full payload is the most common over-permissioning mistake.
Density
What it does: Controls the spacing and compactness of cards and list rows. How to use it: Choose Comfortable when reviewers need to read summaries carefully. Choose Compact when experienced operators are working high volume and know the process well. Why / recommended default: Comfortable is safer for mixed audiences; Compact is better for mature ops desks. The common mistake is using Compact too early and making new users miss important context.
Show timeline
What it does: Shows workflow, messaging, and audit history alongside the work item. How to use it: Turn it on when operators need to see how the item got here or whether someone already touched it. Turn it off only for extremely simple, high-speed queues. Why / recommended default: For most Work Queue screens, On is the recommended default because it reduces back-and-forth debugging. The common mistake is hiding the timeline and then opening another screen just to answer basic history questions.
Require claim before action
What it does: Decides whether a user must claim an item before they can act on it. How to use it: Leave it Off when items are already effectively assigned or when speed matters more than ownership locks. Turn it On for shared team desks where two people might otherwise complete the same item. Why / recommended default: The registry default for Work Queue is Off. That is a good default for lighter-weight follow-up queues, but shared operations teams should consider turning it on once parallel handling becomes a problem.
Available actions
This section controls what users can actually do from the queue. For Work Queue the action set is intentionally small: claim the work if needed, then complete it when the human step is finished.
Claim
What it does: Takes ownership of an unclaimed item so other users can see who is handling it.
How to use it: Keep Claim available on any shared queue where ownership matters. Pair it with Require claim before action when you need a strict handoff model.
Why / recommended default: Claim makes shared desks safer and easier to coordinate. The common mistake is hiding Claim while still expecting teams to avoid duplicate work manually.
Complete
What it does: Marks the work item done and lets the workflow or runtime state move forward when applicable. How to use it: Keep Complete on the screen unless the work should always branch into another action such as approve or escalate. Make sure operators understand what "done" means in the business process. Why / recommended default: Complete is the core action for this screen. A common mistake is using Work Queue for work that really needs structured outcomes, in which case Decision is a better fit.
After-action screen
What it does: Opens another screen after a queue action succeeds. How to use it: Send users to Workflow Status when they need proof the route continued, to Conversation when discussion usually follows, or to a confirmation/content screen for a cleaner finish. Why / recommended default: This is optional, not required. The common mistake is confusing after-action routing with Submission review, which happens before the action and stays in the modal.
Target workflow
What it does: Supplies the destination workflow for actions that launch or escalate into another process. How to use it: Work Queue usually does not need this for Claim or Complete, but it becomes important if you add escalation-style actions later. Pick the exact published workflow that should start next. Why / recommended default: Leave it unset unless an action explicitly needs it. Unnecessary workflow bindings create confusion during maintenance.
Preview scenario
Preview controls let makers test the queue with realistic device sizes, personas, and runtime states before publishing. For operational screens, preview is where you catch most empty-state and claimed-by-other problems early.
Device and orientation
What it does: Changes the preview frame to desktop, tablet, or mobile in portrait or landscape. How to use it: Always check mobile even if the queue is mainly desktop-facing, because field teams and approvers often open operational screens on phones. Use landscape only when you know tablets or kiosks are part of the workflow. Why / recommended default: Responsive failures are easy to miss in a desktop-only preview. Mobile verification is one of the highest-value final checks.
Test persona
What it does: Simulates the user role viewing the queue. How to use it: Preview as the real worker, not just as Admin. For this screen the default persona is Technician, which is a good starting point when the queue is meant for doers rather than system owners. Why / recommended default: Admin previews can hide role-based problems. The common mistake is validating only as an all-powerful user and shipping a queue that ordinary staff cannot use.
Preview state
What it does: Simulates states such as Empty, Loading, Error, Waiting approval, Claimed by me, and Claimed by someone else. How to use it: Walk through the blocked and claimed-by-other states deliberately. Those are the states where queue policy problems become obvious. Why / recommended default: The default preview state for Work Queue is Waiting approval, which is useful because it resembles a real actionable item. Makers often forget to check the failure states until after launch.
Test mode
What it does: Switches between simulated preview and live runtime testing. How to use it: Use simulated preview for layout and copy checks, then use a live test with a real workflow item before publishing. Why / recommended default: Simulated preview is fast, but only live testing proves that bindings and permissions are correct.
Empty state and sample data
Even healthy queues are empty sometimes. This section controls whether the screen feels calmly idle or accidentally broken when there is nothing to work on.
Empty title
What it does: Sets the headline shown when no items match the current queue filters.
How to use it: Keep the default No work is waiting unless you have a clearer phrase for your audience. Prefer language that sounds complete rather than alarming.
Why / recommended default: A good empty title reassures users that the queue is simply clear. Titles that sound like errors make people file unnecessary support requests.
Empty description
What it does: Adds supporting text that explains what users should expect when the queue is empty.
How to use it: Keep or adapt the default New tasks and decisions appear here when workflows or messages need a person. If needed, add where users should go next while they wait.
Why / recommended default: Helpful empty copy reduces "is this broken?" confusion. The common mistake is leaving a generic sentence that does not explain why the queue is empty.
Sample item, run, or conversation
What it does: Provides builder-only references for previewing realistic runtime data. How to use it: Attach representative items before taking screenshots, testing review tabs, or validating compact layouts. Swap them out if they no longer reflect the live process. Why / recommended default: Good sample data prevents false confidence. A toy sample can hide long titles, missing documents, or unusual statuses that appear in production.
Recommended Default Setup
Listen scope
Specific workflow (or Entire app for a shared ops inbox)
Visibility
Technician, Supervisor, or Ops role
Payload visibility
Redacted preview
Show timeline
On
Require claim before action
On for shared teams; Off for personal queues
Submission review
Overview fields + full record
Actions
Claim, Complete
Common Configuration Patterns
Team intake queue
Listen to a specific workflow. Require claim. Bind Submission review to the intake details form.
Personal my-work queue
Listen to Entire app or Specific workflow. Claim off if items are already assigned. Compact density.
Testing Checklist
Troubleshooting
Queue is empty but workflows ran
Listen scope is too narrow, Include sheets excludes the source sheet, or visibility hides the items.
Complete is disabled
Require claim before action is on and the item is unclaimed or claimed by someone else.
Review opens blank
Submission screen override is missing or the item has no source_record_id.
Best Practices
Configure Work Queue for one clear user job.
Prefer the narrowest listen scope that still shows the right work.
Keep payload visibility conservative for broad audiences.
Test as an allowed user and a blocked user before publish.
Pair related screens (Decision + Conversation + Workflow Status + Notification Center) instead of overloading one screen.