> 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/screens-and-components/types-of-screens/native-automation-and-operational-screen-guides/workflow-status-screen.md). # Workflow Status 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 **Workflow Status** screen is a live timeline of workflow runs, steps, waits, retries, and outcomes so requesters and operators can see where work stands. Think of this screen as **A progress board for automation runs — read-only by default.** ![Builder view of this screen with the configuration panel open](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FaDpzl1JrdyxppnzmbqQt%2F00-builder-hero.jpg?alt=media) ## Who This Guide Is For This guide is for makers configuring a **Workflow Status** 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: * Requesters need to see whether their submission is waiting, approved, or failed. * Operators need run timelines without opening backend logs. ## What The Screen Is For ### Use Workflow Status when * Requesters need to see whether their submission is waiting, approved, or failed. * Operators need run timelines without opening backend logs. ### Do not use it when * Acting on approvals — use Decision or Work Queue. * Recovering failures — use Exception Resolution. * High-level ops metrics across many surfaces — use Operator Console. ## What Users See In The Live App * Run cards with status, current step, and timestamps. * Timeline of waits, retries, completions, and failures when Show timeline is on. * Safe payload preview based on Payload visibility. | Default | Value | | ------------------------------- | ------------------------------------------------------------------------------ | | Default listen scope | Entire app | | Require claim before action | Off (not used) | | Default preview persona / state | Operator / Live | | Empty title | No workflow runs yet | | Empty description | Runs appear after a workflow starts from a form, button, webhook, or schedule. | ## Required Foundations | Requirement | Why it matters | | ------------------------------------------ | -------------------------------------------------------------- | | Automation screen entitlement | Workflow Status appears in the Automation / Operational group. | | Workflow | 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. Each option is explained in plain language so makers can decide how much run detail to show, who should see it, and how narrow or broad the status view should be. ### Header and screen type This first section labels the read-only status board. Workflow Status works best when the name clearly tells users whether they are looking at their own request progress or an operator-facing run inspector. #### Screen type **What it does:** Sets the native behavior to **Workflow Status**, which renders workflow run state instead of ordinary data rows or claimable tasks.\ **How to use it:** Leave the type as Workflow Status. If users need to take action on an item, pair this screen with Decision, Work Queue, or Exception Resolution instead of trying to make Workflow Status do everything.\ **Why / recommended default:** This screen is meant to explain where work stands, not to complete the work. Makers commonly get better results when they keep it read-only and focused. #### Category **What it does:** Places the screen in the native Automation or Operational grouping.\ **How to use it:** Keep the built-in category and use navigation structure to decide whether users see the screen as a self-service tracker or an operator tool.\ **Why / recommended default:** Clear separation between operational runtime screens and ordinary app screens makes the builder easier to maintain. #### Title **What it does:** Sets the live title shown in navigation and at the top of the page.\ **How to use it:** Use names like `Request status`, `Workflow progress`, or `Ops run status` so people immediately know this screen is informational.\ **Why / recommended default:** Good titles reduce the chance that users open this screen expecting action buttons. #### Description **What it does:** Adds helper text under the title.\ **How to use it:** Explain what users are looking at, such as "Track the current step, timeline, and final outcome of this workflow."\ **Why / recommended default:** A clear description prevents confusion between a status board and a queue. ### Automation source ![Annotated builder screenshot: Automation source](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FcKwaeMp3Ywkaq4ycqqEI%2F01-section-automation-source.jpg?alt=media) This section decides which runs are visible. It is the main control for whether the screen feels like a focused customer status page or a broad operational run log. #### Listen scope **What it does:** Chooses the top-level source of workflow runs shown on the screen.\ **How to use it:** Use **Specific workflow** for a single-process status page, especially for requesters. Use **Entire app** for operators who need one consolidated view. Use **Specific screen or form** when one intake surface is the clearest source boundary.\ **Why / recommended default:** For requester-facing status, **Specific workflow** is usually the safest default. For operational oversight, Entire app is reasonable if the audience is trusted and the screen still feels readable. #### Source screen or form **What it does:** Binds the screen to one form or screen when that scope is selected.\ **How to use it:** Choose the intake surface that starts the workflow runs you want to track. Re-check it after cloning or replacing that screen.\ **Why / recommended default:** This is useful when users think in terms of "the thing I submitted from this page." The common mistake is forgetting to update the binding after a rebuild. #### Workflow **What it does:** Filters the screen to one workflow when **Specific workflow** is selected.\ **How to use it:** Choose the published workflow whose runs should appear. Be careful in apps with staging, demo, or duplicate workflows.\ **Why / recommended default:** Workflow-specific binding keeps status pages easy to reason about and is the best default for end-user progress tracking. #### Messaging channel **What it does:** Narrows message-linked runtime context when workflow status is combined with messaging signals.\ **How to use it:** Use it only when your run tracking depends on a particular messaging route. Otherwise, keep the screen centered on workflow scope.\ **Why / recommended default:** Extra filters are only helpful when they match the actual runtime design. Unnecessary channel filtering is an easy way to hide runs by accident. #### Topic **What it does:** Filters channel-linked context to one topic.\ **How to use it:** Match the topic exactly when a status view should only follow one class of routed events.\ **Why / recommended default:** Topic mismatch commonly looks like "no runs visible," so use it only when the screen really needs that precision. #### Conversation or correlation **What it does:** Limits the screen to one case, request, or thread context.\ **How to use it:** Use this when the screen is embedded in a specific case experience. Leave it broader for reusable status boards.\ **Why / recommended default:** Hard-coding one correlation is powerful but very narrow. Most standalone status screens should avoid it. #### Linked application **What it does:** Binds the screen to a linked NotionApps application when runs are part of an app-to-app handoff.\ **How to use it:** Select it only when the workflow context truly spans apps.\ **Why / recommended default:** Most Workflow Status screens stay local to one app, which keeps troubleshooting simpler. ### App audience and notification prefs These controls are app-level policy. They still matter here because run visibility should align with the same tenant boundaries and role expectations used elsewhere in the app. #### Tenant mode **What it does:** Decides whether run visibility is partitioned by tenant relationship.\ **How to use it:** Use **Relation** when customers or departments should only see their own workflow progress. Use **Off** only in simple single-tenant apps.\ **Why / recommended default:** Tenant isolation is usually the right default for requester-facing status pages. It prevents status leakage across clients or teams. #### Tenant field **What it does:** Selects the Users-sheet relation that defines tenant membership.\ **How to use it:** Point at the same company, client, or workspace field the rest of the app already uses.\ **Why / recommended default:** Consistency matters. A status page that uses a different tenant model from the rest of the app will feel broken even when the workflow is healthy. #### Role field **What it does:** Tells the platform which field stores a user's role if it is not named `Role`.\ **How to use it:** Leave blank for the default or set it explicitly for a custom role field.\ **Why / recommended default:** Role-driven visibility depends on the right field. This is easy to miss in cloned apps. #### Notification categories **What it does:** Maps notification categories to user preference fields.\ **How to use it:** Keep only real categories that matter to the workflows shown on the status screen.\ **Why / recommended default:** Clean policy mapping makes the whole automation experience easier to understand, even when this screen itself is read-only. #### Add notification category **What it does:** Adds another category row to the app-wide audience policy.\ **How to use it:** Add one only when a workflow actually sends that category and users have a matching preference field.\ **Why / recommended default:** Unused categories add policy noise without improving the status experience. #### Save audience policy **What it does:** Saves the audience and notification policy at the app level.\ **How to use it:** Save after policy changes before retesting with another persona.\ **Why / recommended default:** Unsaved policy changes often look like runtime bugs when they are not. ### Template setup state This section is a health hint for cloned or repaired apps. #### Setup state indicator **What it does:** Shows whether automation bindings are provisioned, need review, or have no setup report.\ **How to use it:** Treat **Needs review** as a prompt to re-check the workflow binding before trusting the status board.\ **Why / recommended default:** It is a quick way to catch broken template remaps before users start reporting empty screens. ### Related context This panel helps you find nearby forms, workflows, and follow-up screens without hunting manually. #### Related context panel **What it does:** Shows read-only counts and related runtime objects.\ **How to use it:** Use it to locate the forms that start the workflow, the screens you may route to next, and the neighboring automation surfaces that belong with this status page.\ **Why / recommended default:** Discovery tools reduce guesswork and help makers avoid duplicate screens. ### Visibility and access ![Annotated builder screenshot: Visibility and access](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FMMmLPKa1vkcUbpzMgaNd%2F02-section-visibility-and-access.jpg?alt=media) Visibility matters here because Workflow Status is often shared with broader audiences than the action screens it sits beside. #### Visibility rules **What it does:** Applies condition-based screen visibility.\ **How to use it:** Build simple conditions using role, tenant, or team membership.\ **Why / recommended default:** Requesters and operators often need different status boards. Clear rules prevent accidental oversharing. #### Allowed role names **What it does:** Adds a direct role allow list.\ **How to use it:** Use roles like `Requester`, `Operator`, or `Admin` depending on the purpose of the page.\ **Why / recommended default:** A short, explicit role list is usually easier to audit than complex nested rules. #### Allowed users **What it does:** Grants access to named people.\ **How to use it:** Use sparingly for pilots, executives, or break-glass support access.\ **Why / recommended default:** Individual exceptions are useful, but they should not become the main access model. ### Display and action policy ![Annotated builder screenshot: Display and action policy](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2F9FDZPiydSmecyhZT696C%2F03-section-display-and-action-policy.jpg?alt=media) For Workflow Status, this section mostly decides how much detail the screen shows. Because the screen is read-only, payload visibility and timeline design matter more than action configuration. #### Screen title override **What it does:** Refines the user-facing title.\ **How to use it:** Name the exact job of the page, such as `Track your request` or `Operations run status`.\ **Why / recommended default:** Clear wording helps users understand this is a status view, not an action desk. #### Description **What it does:** Sets the helper text under the title.\ **How to use it:** Explain what the timeline shows and what users should do if they need to take action elsewhere.\ **Why / recommended default:** One sentence of guidance can prevent a lot of navigation confusion. #### Payload visibility **What it does:** Controls whether the run shows metadata only, a redacted preview, or fuller payload detail.\ **How to use it:** Use **Metadata only** for customer-facing status pages, **Redacted preview** for most internal visibility, and **Full payload** only for trusted operators who really need the raw run data.\ **Why / recommended default:** The right setting depends on audience, but **Metadata only** and **Redacted preview** are usually the safest defaults. Full payload should be rare and intentional. #### Density **What it does:** Chooses comfortable or compact spacing for the run list and detail layout.\ **How to use it:** Use **Comfortable** for requester-friendly status pages and **Compact** for operator-heavy boards.\ **Why / recommended default:** Dense layouts are useful for ops, but they can make a self-service tracker feel harder to read. #### Show timeline **What it does:** Shows the run timeline, including waits, retries, and outcome transitions.\ **How to use it:** Leave **On** for most Workflow Status screens. It is the main reason people open this screen.\ **Why / recommended default:** Timeline visibility is one of the most valuable parts of the status experience. Turning it off usually removes the very context people need. #### Require claim before action **What it does:** Exists in the shared policy panel, but this screen does not use claim behavior by default.\ **How to use it:** Leave it **Off**. Workflow Status is read-only in the default registry configuration.\ **Why / recommended default:** This setting is not meaningful for the standard screen, so changing it usually adds confusion without changing behavior. ### Available actions Workflow Status is read-only by default. That is a feature, not a gap: the screen is designed to answer "what is happening?" rather than "what should I click next?" #### Default action set **What it does:** The registry ships this screen with no claim, complete, or decision actions.\ **How to use it:** Keep it that way for most builds. Pair the screen with Work Queue, Decision, or Exception Resolution elsewhere in navigation if users need to act.\ **Why / recommended default:** Read-only behavior makes the screen safe for broader audiences and prevents accidental edits from a page meant for monitoring. #### After-action screen **What it does:** Exists only if you later add custom actions.\ **How to use it:** Most makers leave this unused. If you extend the screen later, route users to the next logical operational page, not back into a loop.\ **Why / recommended default:** Leaving it blank is the normal default. Workflow Status does not need forced navigation after read-only viewing. #### Target workflow **What it does:** Supplies a workflow binding for custom launch or escalation actions if you add them later.\ **How to use it:** Leave it empty on the standard read-only screen.\ **Why / recommended default:** Adding a target workflow without a matching action only creates maintenance noise. ### Preview scenario ![Annotated builder screenshot: Preview scenario](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FCFi08b6KYEEqVFk3Fjgk%2F04-section-preview-scenario.jpg?alt=media) Preview controls help you check both audience fit and state coverage. #### Device and orientation **What it does:** Changes the preview frame across desktop, tablet, and mobile sizes.\ **How to use it:** Always check mobile if requesters may track progress from a phone.\ **Why / recommended default:** A status page is often opened on the go, so mobile readability matters even when other automation screens are desktop-first. #### Test persona **What it does:** Simulates who is viewing the status board.\ **How to use it:** Use **Operator** for ops-focused screens and switch to requester-like personas when building self-service tracking experiences.\ **Why / recommended default:** Persona testing helps you catch when the payload or timeline is appropriate for one audience but too detailed for another. #### Preview state **What it does:** Simulates states like Live, Empty, Loading, or Error.\ **How to use it:** Check **Live**, **Empty**, and **Error** at minimum. Those three states tell you whether the page feels useful, calm, and trustworthy.\ **Why / recommended default:** The default preview state is **Live**, which is good for checking the core timeline, but the empty state deserves equal attention. #### Test mode **What it does:** Switches between simulated preview and live runtime testing.\ **How to use it:** Use simulated mode for layout, then confirm with a real run in live mode.\ **Why / recommended default:** Only live testing proves that the source binding and visibility rules are correct. ### Empty state and sample data ![Annotated builder screenshot: Empty state and sample data](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2F9ZGBXcd0UDDjKPTf51xd%2F05-section-empty-state-and-sample-data.jpg?alt=media) Read-only status screens are often empty in new apps or quiet periods, so the empty experience should feel informative rather than alarming. #### Empty title **What it does:** Sets the headline shown when no runs match the current scope.\ **How to use it:** Keep the default `No workflow runs yet` unless your audience uses more familiar language.\ **Why / recommended default:** The default is clear and calm. It signals inactivity, not failure. #### Empty description **What it does:** Explains when runs will appear.\ **How to use it:** Keep or adapt the default `Runs appear after a workflow starts from a form, button, webhook, or schedule.`\ **Why / recommended default:** This text answers the first question new users ask when the page is empty. #### Sample item, run, or conversation **What it does:** Lets you preview with realistic runtime references.\ **How to use it:** Use a sample run that includes multiple timeline events so you can verify the page is actually useful before publishing.\ **Why / recommended default:** Rich sample data is especially important on a read-only screen because the timeline itself is the product. ## Recommended Default Setup | Setting | Recommended value | | ------------------ | ---------------------------------------------------------------- | | Listen scope | Specific workflow for requester status; Entire app for operators | | Visibility | Requester role for self-status; Operator/Admin for ops | | Payload visibility | Metadata only for customers; Redacted for internal | | Show timeline | On | | Actions | None (read-only) | ## Common Configuration Patterns ### Requester status page Specific workflow, Metadata only, visible to requesters. ### Ops run inspector Entire app or Specific workflow, Redacted/Full payload, Operator role. ## Testing Checklist * [ ] Start a workflow and confirm a run card appears. * [ ] Wait for a decision step and confirm Waiting state shows. * [ ] Complete the run and confirm Completed state. * [ ] Force a failure and confirm failure appears (or is routed to Exception Resolution). ## Troubleshooting ### No runs visible Listen scope excludes the workflow, or the user lacks visibility. ### Timeline missing Show timeline is off. ## Best Practices * Configure **Workflow Status** 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.