> 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/operator-console-screen.md). # Operator Console 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 **Operator Console** screen is a high-level operational dashboard for runs, queue depth, failures, messages, and audit activity. Think of this screen as **A cockpit for app owners and operators — mostly read-only oversight.** ![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%2F2qBsfpf8EIG2m8jjqkiB%2F00-builder-hero.jpg?alt=media) ## Who This Guide Is For This guide is for makers configuring an **Operator Console** 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: * Owners need a single place to monitor automation health. * Support needs queue depth, failures, and recent activity at a glance. ## What The Screen Is For ### Use Operator Console when * Owners need a single place to monitor automation health. * Support needs queue depth, failures, and recent activity at a glance. ### Do not use it when * Day-to-day claiming of work — use Work Queue. * Approving items — use Decision. * Deep run debugging for one process — use Workflow Status / Exception Resolution. ## What Users See In The Live App * Operational summary cards (runs, failures, queue pressure, messaging activity). * Recent audit / activity when timeline is enabled. * Read-only by default (no claim/complete/decision buttons). | Default | Value | | ------------------------------- | --------------------------------------------------------------------------- | | Default listen scope | Entire app | | Require claim before action | Off (not used) | | Default preview persona / state | Operator / Live | | Empty title | No operations data yet | | Empty description | Workflow, messaging, and automation activity appears after the app is used. | ## Required Foundations | Requirement | Why it matters | | ------------------------------------------ | --------------------------------------------------------------- | | Automation screen entitlement | Operator Console appears in the Automation / Operational group. | | Workflow and Messaging | 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 follow the builder order. Each option is explained in prose so makers can configure an operator-facing oversight surface that stays readable, appropriately restricted, and intentionally read-only. ### Header and screen type This section defines the console at a glance. Operator Console should feel like a high-level monitoring cockpit, not a work queue and not a single-run detail page. #### Screen type **What it does:** Sets the native behavior to **Operator Console**, which renders aggregate operational runtime state instead of ordinary data rows or direct action items.\ **How to use it:** Keep the screen type as Operator Console. Pair it with Workflow Status, Work Queue, or Exception Resolution for the action screens that sit beside it.\ **Why / recommended default:** The console works best as oversight. Trying to turn it into the place where everything also gets done usually makes it harder to monitor anything well. #### Category **What it does:** Places the screen in the native Automation or Operational grouping.\ **How to use it:** Keep the built-in grouping and position the console near the top-level operations navigation.\ **Why / recommended default:** Clear organization helps the console serve as the entry point for operators. #### Title **What it does:** Sets the user-facing title shown in navigation and on the page.\ **How to use it:** Use names like `Operator console`, `Operations overview`, or `Automation health`.\ **Why / recommended default:** The title should signal oversight and monitoring, not case-by-case work. #### Description **What it does:** Adds helper text beneath the title.\ **How to use it:** Explain that the screen shows overall runs, failures, queue pressure, and recent activity.\ **Why / recommended default:** Good description text helps first-time users understand why they are here before they go deeper elsewhere. ### Automation source ![Annotated builder screenshot: Automation source](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2Fmr78lzmZAQANjRNf9vPh%2F01-section-automation-source.jpg?alt=media) This section decides how broad the console is. Most consoles start broad because they are meant to show app-wide health, but focused consoles also make sense for large apps with several operating teams. #### Listen scope **What it does:** Chooses the high-level runtime source shown in the console.\ **How to use it:** Use **Entire app** for a true top-level operations console. Use **Specific workflow** when one team only needs oversight for one process family.\ **Why / recommended default:** Entire app is the usual default because the screen is meant for overview. Narrower scope becomes useful when the app is large enough that one console would otherwise be noisy. #### Source screen or form **What it does:** Binds the console to one local source surface when that scope is selected.\ **How to use it:** Use this only when one intake area needs its own localized operational view.\ **Why / recommended default:** Most consoles are broader than one intake surface. #### Workflow **What it does:** Filters the console to one workflow when **Specific workflow** is selected.\ **How to use it:** Pick the published workflow the operator team owns.\ **Why / recommended default:** A workflow-specific console can be much easier to read than an app-wide one in large, busy apps. #### Messaging channel **What it does:** Narrows the messaging-related operational view to one channel.\ **How to use it:** Use it only when operators need to monitor one message stream closely.\ **Why / recommended default:** Channel filtering is optional and should reflect a real operations use case, not habit. #### Topic **What it does:** Narrows message-linked context to one topic.\ **How to use it:** Use it when the operator team only cares about a specific class of events within a channel.\ **Why / recommended default:** Topic filtering can reduce noise, but it can also hide important signals if applied too early. #### Conversation or correlation **What it does:** Limits the console to one case or one thread context.\ **How to use it:** Use this only for embedded oversight inside a case-specific experience.\ **Why / recommended default:** Most operator consoles should remain broad and reusable. #### Linked application **What it does:** Binds the console to a linked NotionApps application when ops teams need cross-app oversight.\ **How to use it:** Choose it only when partner-app traffic is a meaningful part of what the console should show.\ **Why / recommended default:** Cross-app scope can be powerful, but it is not the standard starting point. ### App audience and notification prefs These app-level settings matter because the console is often one of the most privileged screens in the app and may still need to respect tenant and role boundaries. #### Tenant mode **What it does:** Decides whether operational visibility is isolated by tenant relation.\ **How to use it:** Use **Relation** when delegated operators should only see their own tenant's activity. Use **Off** only for truly centralized or single-tenant internal ops.\ **Why / recommended default:** Broad ops visibility is not always appropriate. Tenant-aware consoles are safer in shared portal environments. #### Tenant field **What it does:** Selects the Users-sheet relation that defines tenant membership.\ **How to use it:** Use the same tenant field the rest of the app relies on.\ **Why / recommended default:** Consistency prevents the console from being the one screen that behaves unexpectedly. #### Role field **What it does:** Tells the platform which field stores a user's role when it is not named `Role`.\ **How to use it:** Set it only for custom user schemas.\ **Why / recommended default:** Role-driven console access depends on this being correct. #### Notification categories **What it does:** Maps categories to user preference fields for the wider app-level notice system.\ **How to use it:** Configure only the categories that really matter to the operations audience.\ **Why / recommended default:** Clean policy keeps the broader operational experience easier to reason about. #### Add notification category **What it does:** Adds another category row.\ **How to use it:** Add one only when a real notification pathway exists.\ **Why / recommended default:** Unused categories increase policy complexity without adding value. #### Save audience policy **What it does:** Saves tenant and category policy at the app level.\ **How to use it:** Save before retesting console visibility as another persona.\ **Why / recommended default:** Unsaved policy can make a healthy console look broken. ### Template setup state This diagnostic section is especially helpful after templates are cloned or demo apps are repaired. #### Setup state indicator **What it does:** Reports whether the native screen bindings are provisioned, need review, or have no setup report.\ **How to use it:** Treat **Needs review** as a prompt to re-check the broad operational bindings before trusting the console.\ **Why / recommended default:** A console with broken bindings can look deceptively calm because "nothing is happening" is also a valid quiet state. ### Related context This read-only panel helps you find the screens and workflows operators may need when they leave the console to investigate. #### Related context panel **What it does:** Shows discovery counts and related runtime objects.\ **How to use it:** Use it to locate Workflow Status, Exception Resolution, Work Queue, and messaging surfaces that belong with the console.\ **Why / recommended default:** Strong operational navigation starts with knowing what related surfaces already exist. ### 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%2F4g2GZcsNyXMyoZc31Abw%2F02-section-visibility-and-access.jpg?alt=media) Operator Console should usually be restricted to admins and operators. It is a broad operational window into the app. #### Visibility rules **What it does:** Applies condition-based screen visibility.\ **How to use it:** Restrict the screen with role, tenant, or team-based conditions so only the right operators can open it.\ **Why / recommended default:** Broad visibility here can reveal more operational detail than many teams realize. #### Allowed role names **What it does:** Adds a direct role allow list.\ **How to use it:** Use focused roles like `Operator, Admin, Support Lead`.\ **Why / recommended default:** A short role list is usually the clearest access model for a console. #### Allowed users **What it does:** Grants access to specific named people.\ **How to use it:** Use for pilots or named operational owners, not as the long-term primary access model.\ **Why / recommended default:** Individual exceptions are best kept rare and deliberate. ### 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%2F33fGFZG37KLF3lANfiyB%2F03-section-display-and-action-policy.jpg?alt=media) This is one of the most important sections on the screen because the console's value depends on seeing the right level of detail without overwhelming the operator. #### Screen title override **What it does:** Refines the live title.\ **How to use it:** Use language that signals a top-level operations view, not a case or queue view.\ **Why / recommended default:** The title should set the user's mental model before they start drilling into details elsewhere. #### Description **What it does:** Sets the helper text beneath the title.\ **How to use it:** Explain that the screen provides high-level health, activity, and audit visibility.\ **Why / recommended default:** This helps users understand that the console is primarily for monitoring. #### Payload visibility **What it does:** Controls whether the console shows metadata only, a redacted preview, or fuller payload detail.\ **How to use it:** Use **Redacted preview** for most internal consoles and **Full payload** only when a trusted operator team truly needs that depth. Use **Metadata only** if the audience is broader or more executive-facing.\ **Why / recommended default:** Payload detail drives the difference between a safe overview and an overexposed ops screen. Conservative defaults age better. #### Density **What it does:** Chooses comfortable or compact spacing for the console.\ **How to use it:** Use **Compact** for dense operator monitoring and **Comfortable** when the audience is broader or less technical.\ **Why / recommended default:** Compact is often a strong choice here because operators usually value more information on screen, but only if readability stays intact. #### Show timeline **What it does:** Shows recent activity and audit history in the console.\ **How to use it:** Leave **On** when you want the console to show recent operational movement instead of only static summary tiles.\ **Why / recommended default:** Timeline visibility is often what turns the console from a passive dashboard into a useful triage surface. #### Require claim before action **What it does:** Exists in the shared policy section, but Operator Console does not use claim behavior in its default model.\ **How to use it:** Leave it **Off**.\ **Why / recommended default:** The console is read-only by default, so claim settings do not normally change behavior. ### Available actions Operator Console is read-only by default. That is the expected setup for most maker-built consoles. #### Default action set **What it does:** Ships with no claim, complete, or decision actions in the standard registry setup.\ **How to use it:** Keep the console read-only and use navigation to direct operators into the right action screens when they need to go deeper.\ **Why / recommended default:** Read-only design is what lets the console safely summarize a lot of information for a trusted audience. #### After-action screen **What it does:** Exists only if you later add custom actions.\ **How to use it:** Most makers leave it unused. If you add actions later, route users into a more focused operational screen such as Workflow Status or Exception Resolution.\ **Why / recommended default:** Blank is the normal default because the console is not primarily an action surface. #### Target workflow **What it does:** Supplies a workflow binding for custom actions if you add them later.\ **How to use it:** Leave it empty on the standard read-only console.\ **Why / recommended default:** Unused bindings add maintenance overhead without improving the screen. ### Preview scenario ![Annotated builder screenshot: Preview scenario](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2F4cWhmH3VOmoIlMXgnWqB%2F04-section-preview-scenario.jpg?alt=media) Preview controls help you validate the console's readability and make sure the empty state does not masquerade as healthy operations. #### Device and orientation **What it does:** Changes the preview frame across desktop, tablet, and mobile sizes.\ **How to use it:** Check the main operator device first, then validate mobile if leadership or support may glance at the console on phones.\ **Why / recommended default:** Dense overview screens are especially sensitive to smaller layouts. #### Test persona **What it does:** Simulates the viewer role.\ **How to use it:** Test as the real operator or admin role that will use the console.\ **Why / recommended default:** Persona testing catches access and visibility issues before publish. #### Preview state **What it does:** Simulates states such as Live, Empty, Loading, and Error.\ **How to use it:** Check **Live** for information density and **Empty** to make sure a quiet system still reads clearly.\ **Why / recommended default:** The default preview state is **Live**, but quiet periods are normal on some consoles, so the empty state deserves equal attention. #### Test mode **What it does:** Switches between simulated preview and live runtime testing.\ **How to use it:** Use live testing with real automation activity before publish so you can verify that the console is not silently too narrow.\ **Why / recommended default:** Only a live test confirms that the data volume and scope feel right. ### 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%2FaxdtmjNT2u6p3E96lRm5%2F05-section-empty-state-and-sample-data.jpg?alt=media) A broad console can be quiet when an app is new or traffic is low. The empty state should make that calm understandable. #### Empty title **What it does:** Sets the headline shown when no operational data matches.\ **How to use it:** Keep the default `No operations data yet` unless your team uses more specific operational wording.\ **Why / recommended default:** The default clearly signals low or absent activity, not a rendering failure. #### Empty description **What it does:** Explains when data will begin to appear.\ **How to use it:** Keep or adapt the default `Workflow, messaging, and automation activity appears after the app is used.`\ **Why / recommended default:** This copy helps new operators understand that an empty console can be expected in fresh apps. #### Sample item, run, or conversation **What it does:** Provides builder-only sample references for preview and QA.\ **How to use it:** Use samples with a mix of success, backlog, and failure signals so you can judge whether the console is actually useful.\ **Why / recommended default:** Thin sample data can make any console look good. Realistic samples show whether the overview still works once the app gets busy. ## Recommended Default Setup | Setting | Recommended value | | ------------------ | --------------------------- | | Listen scope | Entire app | | Visibility | Admin / Operator only | | Payload visibility | Redacted preview | | Show timeline | On | | Density | Compact for dense ops views | | Actions | None | ## Common Configuration Patterns ### Owner morning console Entire app, Admin/Operator, compact, timeline on. ### Support triage hub Pair with Exception Resolution and Work Queue links in navigation. ## Testing Checklist * [ ] Generate workflow, queue, and notification activity and confirm console populates. * [ ] Confirm non-operators cannot open the screen. * [ ] Confirm empty state before first activity. ## Troubleshooting ### Always empty App has no automation traffic yet, or visibility restricts the viewer. ### Too noisy Narrow listen scope or reduce payload visibility. ## Best Practices * Configure **Operator Console** 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.