📊Workflow Status
Workflow Status 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 Workflow Status screen shows workflow run progress inside the live app. It helps users and owners understand what started, what is waiting, what retried, what failed, and what completed.
Think of this screen as a readable timeline for an automation process. 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 Workflow Status 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:
Users need visibility into workflow progress.
A maker wants to expose run status without giving admin log access.
A process has waits, retries, or handoffs that users ask about.
Support needs a customer-safe view of where a workflow is stuck.
What The Screen Is For
Use Workflow Status when the job is transparency. It is usually read-only and should explain progress in plain language rather than exposing internal route machinery first.
Good examples:
A requester checks whether their submitted request is pending review.
An owner sees which workflow run failed.
A webhook intake process shows accepted and waiting events.
An onboarding flow shows completed and waiting steps.
A customer-facing status page reduces support questions.
Bad examples:
Users need to claim or complete work. Use Work Queue.
Users need to approve or reject. Use Decision.
Users need a conversation. Use Conversation.
Owners need app-wide metrics. Use Operator Console.
Users need to start a workflow. Use Automation Launcher.
The Mental Model
A Workflow Status 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 Workflow runs and, when enabled, a Timeline section. Each run card shows workflow name, status, last error if present, run short reference, and start time.
A live Workflow Status screen can show:
Workflow run name or short run reference.
Run status, such as running, waiting, failed, cancelled, or completed.
Last error when the run has one.
Started or created timestamp.
Timeline entries for steps, waits, messages, item changes, and audit events.
Empty state when no matching runs exist.
Workflow Status is not an admin log viewer. It should give enough information to answer user questions while keeping technical support references hidden unless intentionally exposed.
Required Foundations And Entitlements
Workflow Status requires Workflow Foundation. Messaging is optional when messages are part of the workflow story and appear as related timeline activity.
Operational screen entitlement
Workflow Status appears in the Operational group.
Workflow Foundation
Run state and timeline state come from workflow runtime.
A selected workflow or source
Without a source, the status page may be too broad or empty.
Visibility rules, recommended
Status visibility should match who is allowed to know process state.
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 Workflow Status, the maker should name the screen for the user job, not for the internal system. Use names like Request Status, Workflow Timeline, Process Status, Submission Progress. 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 Workflow Status, the source decides which workflow runs appear. A requester-facing status page should usually be specific. An owner-facing status page can be broad.
Entire app
Use for owner/operator visibility across many workflows.
Specific screen or form
Use when users should see status for work submitted from one form.
Specific workflow
Best default for one process timeline.
Conversation or message thread
Use when messages start or resume the workflow.
Linked application
Use when a linked app exchange drives the workflow status.
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 Workflow Status, 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:
Finding the workflow whose runs should appear.
Loading recent runs for sample preview.
Checking hidden forms that trigger the workflow.
Selecting related status or detail screens for navigation.
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 Workflow Status:
Requester-facing status: restrict to the requester or their organization.
Owner-facing status: restrict to Admin, Operator, or Support.
Customer apps: use metadata-only or redacted payload.
Internal apps: timeline can be more detailed, but still avoid raw IDs unless needed.
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 process users are tracking.
Request Status or Workflow Timeline
Description
Explains what status means and when users should take action elsewhere.
Track where this request is in the workflow.
Payload visibility
Controls whether run details expose submitted data.
Metadata only for customers; redacted preview for operators.
Density
Controls run card spacing.
Comfortable for single-process pages; compact for owner views.
Show timeline
Controls whether timeline entries appear.
On.
Require claim before action
Usually irrelevant because the screen is read-only.
Off.
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.
None
Read-only
This screen is informational by default.
Workflow Status is read-only by default. If a user needs to act, route them to Work Queue, Decision, Conversation, or Automation Launcher instead of adding status-page buttons that blur the purpose.
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 Workflow Status, preview these states before publishing:
Live data, to inspect real run cards.
Empty, to show no runs yet.
Loading, to verify slow runtime behavior.
Error, to verify setup/access copy.
Overdue or waiting states, to check how waiting runs read on mobile.
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 Workflow Status should answer:
Has the workflow never run?
Is the user looking at the wrong process?
Should they submit a form first?
Should an admin check workflow setup?
Common Configuration Patterns
Workflow Status works best when it is tied to one process and a clear audience.
Requester Status Page
A user submits a form and later checks progress.
Recommended configuration:
Listen scope: Specific screen or form.
Visibility: requester-matched rule.
Payload visibility: metadata only or redacted preview.
Timeline: on.
Empty copy: no request has started yet.
Owner Workflow Monitor
An owner watches a critical workflow for failures.
Recommended configuration:
Listen scope: Specific workflow.
Visibility: Admin/Operator.
Payload visibility: redacted preview.
Density: compact if many runs occur.
Timeline: on.
Webhook Intake Status
A support user checks whether external events became workflow runs.
Recommended configuration:
Listen scope: Specific workflow.
Access: Support/Admin.
Payload visibility: metadata only first.
Timeline: on with errors visible.
Testing Checklist
Before publishing or handing this screen to a customer, test the following.
Troubleshooting
No workflow runs appear
What it usually means:
The workflow has not run, the source binding is wrong, or visibility hides the runs.
What to check:
Confirm workflow ID in Automation source.
Trigger a fresh workflow run.
Check sample workflow run selector.
Review template setup state.
Users see technical errors
What it usually means:
Payload or error details are too exposed for the audience.
What to check:
Switch payload visibility to metadata only or redacted preview.
Edit screen description to explain what users should do.
Use Operator Console for internal diagnostics.
Status looks stale
What it usually means:
The runtime has not refreshed or the selected workflow run is old.
What to check:
Pull to refresh in live app.
Check generated_at timestamp.
Trigger a fresh run.
Confirm source binding is not pointing to an old cloned workflow.
Best Practices
Use Workflow Status for transparency, not actions.
Prefer specific workflow or form scope for customer-facing status.
Keep payload visibility conservative.
Use timeline for processes with waits and retries.
Write empty copy that tells users whether a process has started.
Use Operator Console for broad operational health.
Recommended Default Setup
Use this as a safe first configuration when the maker is unsure.
Listen scope: Specific workflow.
Access: requester-matched rule for customer status or Admin for internal status.
Payload visibility: Metadata only or Redacted preview.
Show timeline: on.
Require claim before action: off.
Preview mode: live test with a real run.