💻Operator Console
Operator Console 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 Operator Console screen is a high-level operational dashboard for automation activity. It summarizes workflow, messaging, queue, exception, delivery, link, and timeline health for trusted users.
Think of this screen as an in-app control room for automation health. 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 an Operator Console 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:
Owners need a health overview without backend logs.
Support needs to inspect queue depth and failed runs.
An operations team monitors automation activity.
A maker needs to distinguish high-level monitoring from user task screens.
What The Screen Is For
Use Operator Console when the user owns operational health. It is usually read-only and broader than Workflow Status. It tells an operator whether work is flowing, waiting, failing, or backing up.
Good examples:
An app owner sees failed runs and waiting runs.
Support checks queue depth before investigating a complaint.
Operations monitors failed deliveries and active linked app routes.
A template demo includes an internal health page.
Admins inspect recent automation timeline without backend logs.
Bad examples:
Ordinary end users checking their request status. Use Workflow Status.
Users claiming tasks. Use Work Queue.
Users approving requests. Use Decision.
Users chatting. Use Conversation.
Users launching actions. Use Automation Launcher.
The Mental Model
A Operator Console 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 a metrics grid and timeline. Metrics include open items, failed runs, waiting runs, queue depth, failed deliveries, and active links.
A live Operator Console screen can show:
Open item count.
Failed workflow run count.
Waiting workflow run count.
Queue depth.
Failed delivery count.
Active linked app count.
Timeline entries when enabled.
Empty or zero-state metrics when no runtime activity exists.
Operator Console should be treated as sensitive. Even when payloads are hidden, counts and failure patterns can reveal operational information about a business.
Required Foundations And Entitlements
Operator Console normally requires Workflow Foundation and benefits from Messaging Foundation. It reads summary state across runtime systems, so broad access should be limited.
Operational screen entitlement
Operator Console appears in the Operational group.
Workflow Foundation
Run and queue metrics depend on workflow state.
Messaging Foundation, recommended
Delivery failures, message activity, and linked app metrics depend on messaging state.
Admin/operator access rules
The console exposes operational health. It should not be public.
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 Operator Console, the maker should name the screen for the user job, not for the internal system. Use names like Operations Console, Automation Health, Runtime Monitor, App Operations. 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 Operator Console, source binding decides the monitoring boundary. Entire app is common. Specific workflow or form is useful for a focused operations page.
Entire app
Best default for app-wide operational health.
Specific screen or form
Use for monitoring one intake route.
Specific workflow
Use for a critical workflow monitor.
Conversation or message thread
Use for messaging-heavy operations.
Linked application
Use for monitoring one app-to-app integration.
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 Operator Console, 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:
Checking available workflows and channels before choosing scope.
Finding generated recipes included in a template.
Selecting a sample workflow run for preview.
Confirming hidden operational screens exist for routing.
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 Operator Console:
Restrict to Admin, Operator, Support, or app owner roles.
Use allowed users for small teams.
Do not expose to ordinary customers or employees.
Use separate customer-safe Workflow Status screens for end users.
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 operations dashboard.
Operations Console or Automation Health
Description
Explains what health the console summarizes.
Monitor workflow, messaging, queues, and failures.
Payload visibility
Usually controls timeline details rather than item cards.
Metadata only or redacted preview.
Density
Controls dashboard spacing.
Compact for dense operations; comfortable for demos.
Show timeline
Shows recent operational events.
On.
Require claim before action
Not relevant because console 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.
Operator Console is read-only by default. If operators need action buttons, route them to Work Queue, Exception Resolution, Automation Launcher, or Workflow Status instead of overloading the console.
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 Operator Console, preview these states before publishing:
Live data, to inspect real metrics.
Empty, to verify zero-state dashboard.
Error, to verify support copy.
Overdue/waiting, to inspect waiting run counts.
Desktop and tablet, because operations dashboards are usually wide.
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 Operator Console should answer:
Does zero mean healthy or not configured?
Should the operator run a test workflow?
Does the screen explain where to look next?
Common Configuration Patterns
Operator Console should be broad enough for health monitoring but narrow enough that the operator understands what the metrics mean.
App-Wide Health Console
An app owner monitors all automation activity.
Recommended configuration:
Listen scope: Entire app.
Visibility: Admin/Operator.
Payload visibility: metadata only.
Timeline: on.
Density: compact.
Critical Workflow Monitor
Support watches one workflow closely.
Recommended configuration:
Listen scope: Specific workflow.
Visibility: Support/Admin.
Sample workflow run: recent failed or waiting run.
Timeline: on.
Linked App Operations
A team monitors app-to-app traffic and failures.
Recommended configuration:
Listen scope: Linked application.
Visibility: Operations/Admin.
Messaging Foundation enabled.
Timeline: on.
Testing Checklist
Before publishing or handing this screen to a customer, test the following.
Troubleshooting
All metrics are zero
What it usually means:
The app may have no runtime activity, source binding may be too narrow, or runtime summary is unavailable.
What to check:
Trigger a known workflow.
Switch to Entire app for testing.
Check Workflow Foundation entitlement.
Check Template setup state.
Operators need to fix an item from the console
What it usually means:
The console is doing its job by identifying health, but action should happen on another screen.
What to check:
Add Work Queue for task ownership.
Add Exception Resolution for failures.
Add Workflow Status for run timeline.
Add Automation Launcher for manual starts.
End users can see operational metrics
What it usually means:
Visibility rules are too broad.
What to check:
Restrict allowed roles.
Add allowed users.
Test as end user.
Hide the screen from normal navigation if needed.
Best Practices
Keep Operator Console internal.
Use metrics as signals, not full diagnostics.
Pair with Workflow Status and Exception Resolution for drill-down.
Prefer metadata-only payload visibility.
Use compact density for high-volume apps.
Review access rules after cloning templates.
Recommended Default Setup
Use this as a safe first configuration when the maker is unsure.
Listen scope: Entire app.
Visibility: Admin/Operator/Support.
Payload visibility: Metadata only.
Show timeline: on.
Density: compact.
Require claim before action: off.
Preview state: live and empty.