⚙️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.