> 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.md). # Automation Screens ## Native Automation And Operational Screen Guides > Current state: native Automation and Operational screens are entitlement-gated surfaces inside **Automation (Beta Testing)**. They use the same broad app-screen model as data screens, but they read NotionApps runtime state instead of ordinary Notion database rows. NotionApps native automation screens give makers a way to expose workflow, messaging, queue, decision, notification, exchange, and operational state directly inside a live app. They are not simply different list layouts. A normal data screen reads Notion records. A native automation or operational screen reads platform-owned runtime activity, such as workflow runs, queue items, decision items, messages, announcements, failed work, linked app exchanges, and operator summaries. Use these guides when a maker needs to understand what each screen is for, how each builder section works, and how the live user experience behaves after the app is published. ### Screen Guide Index | Screen | Builder group | Primary job | Primary foundation | | -------------------- | ------------- | -------------------------------------------------------------------------------------- | ---------------------------- | | Work Queue | Automation | Claim, complete, release, or escalate human work created by automation. | Workflow, optional Messaging | | Decision | Automation | Approve, reject, or request changes at a workflow checkpoint. | Workflow | | Conversation | Automation | Read and send contextual messages, replies, and direct chats. | Messaging, optional Workflow | | Exception Resolution | Automation | Review failed or blocked automation and recover safely. | Workflow, optional Messaging | | Notification Center | Automation | Read announcements, alerts, notifications, acknowledgements, and dismissals. | Messaging, optional Workflow | | Linked App Exchange | Automation | Review app-to-app requests, replies, payloads, and link state. | Messaging, optional Workflow | | Workflow Status | Operational | Show workflow runs, waits, retries, failures, and timeline progress. | Workflow | | Automation Launcher | Operational | Manually start approved workflows or operator actions. | Workflow | | Operator Console | Operational | Monitor operational metrics, failures, queue depth, deliveries, and linked app health. | Workflow and Messaging | ### Shared Mental Model Every native automation screen has three layers. | Layer | What it means | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Builder configuration | The maker chooses source binding, access, display, action, preview, and empty-state behavior. | | Runtime state | NotionApps creates or receives workflow, messaging, queue, decision, notification, exception, exchange, and operator state. | | Live screen | End users see a normal app screen that shows only the runtime state they are allowed to see and actions they are allowed to run. | The most important distinction is this: ``` Data screens show Notion records. Native automation screens show NotionApps runtime work. ``` That distinction affects setup, access, testing, and troubleshooting. If a maker expects a Work Queue to behave like a Notion table, they will configure it incorrectly. If a maker expects a Conversation screen to show every row comment, they will miss the messaging channel, topic, conversation, and correlation model. ### Shared Builder Sections Every guide explains the same builder sections, because each native screen uses the shared automation screen configuration component. | Section | What the maker controls | Common mistake | | --------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Header and screen type | The screen category, title, and description users will see. | Naming the screen after internal IDs instead of the user job. | | Automation source | The listen scope: entire app, specific screen/form, workflow, conversation/thread, or linked app. | Choosing Entire app when the screen should be route-specific. | | Template setup state | Whether template provisioning remapped the screen binding correctly. | Ignoring Needs review after cloning or repairing a demo. | | Related context | Available screens, controls, workflows, channels, recent messages, and generated recipe objects. | Copying IDs manually instead of using context-aware pickers. | | Visibility and access | Data-screen style visibility rules plus allowed roles/users. | Exposing operational screens to ordinary users. | | Display and action policy | Title, description, payload visibility, density, timeline, and claim requirement. | Showing too much payload or requiring claim where it does not make sense. | | Available actions | What buttons users can press and where actions route afterward. | Adding actions to screens that should be read-only. | | Preview scenario | Device, orientation, persona, state, and preview mode for testing. | Publishing after only testing the happy path. | | Empty state and sample data | No-data copy and sample runtime references for preview. | Empty copy that sounds like a broken integration. | ### Choosing The Right Screen Use this quick decision table before adding a native screen. | User job | Best screen | Why | | -------------------------------------------- | -------------------- | ------------------------------------------------------------------------- | | See work that needs ownership and completion | Work Queue | Work Queue has claim, release, complete, and escalate behavior. | | Answer approve/reject/request changes | Decision | Decision records a structured workflow outcome. | | Ask questions or reply in context | Conversation | Conversation is backed by Messaging and supports threaded replies. | | Recover failed or blocked automation | Exception Resolution | Exception Resolution is for repair, escalation, and failed-work recovery. | | Read durable notices | Notification Center | Notifications persist after transient messages disappear. | | Inspect app-to-app handoffs | Linked App Exchange | It is scoped to linked applications and exchange traffic. | | Track where a workflow run is | Workflow Status | It shows run cards and timeline progress. | | Start an approved manual automation | Automation Launcher | It gives trusted users a controlled launch action. | | Monitor app automation health | Operator Console | It summarizes operational metrics and recent runtime activity. | ### Safe Defaults When a maker is unsure, start conservative. * Use **Specific workflow** instead of **Entire app** for most user-facing screens. * Use **Redacted preview** or **Metadata only** payload visibility unless the audience is internal support. * Keep operational screens restricted to Admin, Operator, Support, or Supervisor roles. * Turn **Show timeline** on for status, exception, operator, and internal queue screens. * Turn **Require claim before action** on for shared Work Queue and Decision screens. * Test with at least one allowed user and one disallowed user. * Test empty, loading, error, mobile, and claimed-by-other states before publishing. ### GitBook Publishing Note These Markdown files are written to be copied or imported into GitBook as standalone maker guides. Each screen guide intentionally repeats the shared builder sections so a maker can land on any one page and still understand the full configuration model without reading the entire folder first.