> 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/automation-launcher-screen.md). # Automation Launcher 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 **Automation Launcher** screen is a controlled launchpad for manual workflow starts, service requests, and operator announcements. Think of this screen as **A trusted start button panel — users intentionally begin automation.** ![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%2FHKWhCkYSLgbVxzCefcK7%2F00-builder-hero.jpg?alt=media) ## Who This Guide Is For This guide is for makers configuring an **Automation Launcher** 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: * Operators must manually start an approved workflow. * Staff need a safe place to publish announcements. * Service requests should start without exposing the whole workflow builder. ## What The Screen Is For ### Use Automation Launcher when * Operators must manually start an approved workflow. * Staff need a safe place to publish announcements. * Service requests should start without exposing the whole workflow builder. ### Do not use it when * Automatic starts from form submit — configure the workflow trigger instead. * Approving work — use Decision. * Monitoring runs — use Workflow Status / Operator Console. ## What Users See In The Live App * Launch actions configured on the screen. * Publish announcement and Launch workflow buttons. * Empty state when no launch actions are configured. | Default | Value | | ------------------------------- | ----------------------------------------------------------------- | | Default listen scope | Entire app | | Require claim before action | Off | | Default preview persona / state | Operator / Live | | Empty title | No launch actions configured | | Empty description | Add workflow or messaging actions to make this screen actionable. | ## Required Foundations | Requirement | Why it matters | | ------------------------------------------ | ------------------------------------------------------------------ | | Automation screen entitlement | Automation Launcher appears in the Automation / Operational group. | | Workflow | 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 a launch surface that is safe, deliberate, and clear about which workflows or announcements it can start. ### Header and screen type This section defines the launcher itself. Automation Launcher should feel like a controlled control panel, not a general-purpose workspace. #### Screen type **What it does:** Sets the native behavior to **Automation Launcher**, which renders manual launch actions instead of runtime items or Notion rows.\ **How to use it:** Keep the screen type as Automation Launcher. If a workflow should start automatically, configure the trigger in the workflow instead of sending users here.\ **Why / recommended default:** Launchers are best for intentional human-start actions. Using them for automatic flows usually adds extra clicks without adding control. #### Category **What it does:** Places the screen in the native Automation or Operational grouping.\ **How to use it:** Keep the default grouping and put the launcher near the operational tools the same audience already uses.\ **Why / recommended default:** Good grouping helps makers separate action launch surfaces from monitoring surfaces. #### Title **What it does:** Sets the live title shown to users.\ **How to use it:** Use names like `Operations launcher`, `Service actions`, or `Admin tools` so the audience understands this is a start point.\ **Why / recommended default:** The title should signal deliberate action. Vague titles make users unsure whether they are allowed to click. #### Description **What it does:** Adds helper text beneath the title.\ **How to use it:** Explain what kinds of launches belong here and whether the screen is restricted to trusted staff.\ **Why / recommended default:** One clear sentence prevents accidental misuse. ### Automation source ![Annotated builder screenshot: Automation source](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FqOuQngRmMHSERrELPgzG%2F01-section-automation-source.jpg?alt=media) Automation Launcher does not depend on a live queue of incoming items, but it still uses the shared source section. Makers should use it to keep the launch panel aligned with the workflows or messaging systems it belongs beside. #### Listen scope **What it does:** Chooses the high-level automation context the launcher is associated with.\ **How to use it:** Use **Entire app** for a general admin launcher or **Specific workflow** when the launcher should only relate to one process family.\ **Why / recommended default:** Entire app is a reasonable default for trusted operations panels, but narrower workflow context can make the launcher easier to understand. #### Source screen or form **What it does:** Binds the launcher to one source surface when that scope is selected.\ **How to use it:** Use this when launches should be conceptually tied to one intake or one app area.\ **Why / recommended default:** This is more about clarity than necessity. Most launchers remain broad unless they support one specific process. #### Workflow **What it does:** Filters the launcher's context to one workflow when **Specific workflow** is selected.\ **How to use it:** Pick the workflow family the launcher belongs to, especially when the screen will be used by one team for one service flow.\ **Why / recommended default:** Workflow-specific context makes a launcher easier to explain and govern. #### Messaging channel **What it does:** Narrows the launcher's messaging context to one channel.\ **How to use it:** Use it when the screen also publishes announcements or other message-driven actions into a known channel.\ **Why / recommended default:** Channel binding is especially useful when Publish announcement is one of the core actions. #### Topic **What it does:** Filters message publishing or context to a specific topic.\ **How to use it:** Use exact, stable topic names when your launcher should publish or align with a specific announcement pattern.\ **Why / recommended default:** Topic drift can make announcements look like they disappeared into the wrong inbox. #### Conversation or correlation **What it does:** Limits launcher context to a specific thread or case.\ **How to use it:** Use this only when the launcher is embedded inside one case experience.\ **Why / recommended default:** Most launchers should stay reusable, so a fixed correlation is usually too narrow. #### Linked application **What it does:** Binds the launcher to a linked NotionApps application when launch actions are part of a cross-app workflow.\ **How to use it:** Choose it only when the action surface truly spans apps.\ **Why / recommended default:** Most manual launch surfaces stay inside one app, which is easier to manage. ### App audience and notification prefs These app-level controls matter here because launchers are usually restricted to trusted roles and may publish announcements that respect notification category policy. #### Tenant mode **What it does:** Decides whether launcher visibility and related runtime context are tenant-aware.\ **How to use it:** Use **Relation** when launch actions should only be visible within a tenant boundary. Use **Off** for simple single-tenant internal tooling.\ **Why / recommended default:** Many launchers are internal-only, but tenant-aware policy still matters in portal-style apps with delegated operators. #### Tenant field **What it does:** Selects the Users-sheet relation that defines tenant membership.\ **How to use it:** Use the same field the rest of the app relies on.\ **Why / recommended default:** Consistency prevents one operational screen from behaving differently than the rest. #### Role field **What it does:** Tells the platform which field stores user roles when it is not named `Role`.\ **How to use it:** Set it only if your user model uses a different field name.\ **Why / recommended default:** Launchers often depend heavily on role gating, so this mapping needs to be correct. #### Notification categories **What it does:** Maps notice categories to preference fields.\ **How to use it:** Configure the categories you plan to use when **Publish announcement** sends notices into Notification Center or email.\ **Why / recommended default:** Category policy matters most when the launcher is used for communication, not just workflow starts. #### Add notification category **What it does:** Adds another category row to the app-level policy.\ **How to use it:** Add one only for real announcement types you expect staff to publish.\ **Why / recommended default:** A small, meaningful category set is easier for makers and users to understand. #### Save audience policy **What it does:** Saves tenant and category policy at the app level.\ **How to use it:** Save before testing who can see or receive launcher-driven announcements.\ **Why / recommended default:** Unsaved policy leads to confusing test results. ### Template setup state This section is a quick health indicator for cloned or repaired apps. #### Setup state indicator **What it does:** Reports whether the screen bindings are provisioned, need review, or have no setup report.\ **How to use it:** Re-check the status after duplicating launch surfaces or re-pointing actions to new workflows.\ **Why / recommended default:** Manual start screens are easy to forget during remaps, so this diagnostic is useful. ### Related context This panel helps you find the workflows, screens, and channels the launcher should coordinate with. #### Related context panel **What it does:** Shows read-only discovery counts and related runtime objects.\ **How to use it:** Use it to locate the target Workflow Status screen, Notification Center, or related intake forms before wiring actions.\ **Why / recommended default:** Seeing the nearby operational landscape helps you create a launch surface that feels intentional. ### 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%2FpOz4ml0zvJPzenYTgzpZ%2F02-section-visibility-and-access.jpg?alt=media) Automation Launcher should usually be one of the most restricted native screens in the app. The screen starts work on purpose, so the audience should be explicit. #### Visibility rules **What it does:** Applies condition-based screen visibility.\ **How to use it:** Restrict the screen by role, tenant, or team so only trusted staff can launch workflows or publish announcements.\ **Why / recommended default:** Broad access is risky here. A launcher is a power tool, not a general navigation page. #### Allowed role names **What it does:** Adds a direct role allow list.\ **How to use it:** Use clear roles like `Operator, Admin, Dispatcher, Support Lead` as needed.\ **Why / recommended default:** Role lists are usually the clearest way to govern a launcher. #### Allowed users **What it does:** Grants access to named people.\ **How to use it:** Use for pilots or named operational owners, not as the long-term main access strategy.\ **Why / recommended default:** Per-user access is convenient short term but hard to maintain at scale. ### 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%2FArSiSOvP6fksuBG0JnPn%2F03-section-display-and-action-policy.jpg?alt=media) This section shapes how lightweight or intimidating the launcher feels. Since the main value is the actions, clear labels matter more than dense runtime detail. #### Screen title override **What it does:** Refines the user-facing title.\ **How to use it:** Use direct, job-oriented wording like `Start a workflow` or `Operations tools`.\ **Why / recommended default:** The title should tell users that clicking here has real operational consequences. #### Description **What it does:** Sets the helper copy under the title.\ **How to use it:** Explain what launches are allowed and when users should use this panel.\ **Why / recommended default:** A short instruction reduces accidental starts. #### Payload visibility **What it does:** Controls how much runtime context is shown on the launcher.\ **How to use it:** Use **Metadata only** for most launchers. Use **Redacted preview** or **Full payload** only if operators truly need extra context before launching.\ **Why / recommended default:** Launchers usually do not need heavy payload detail. Keeping them lighter makes the screen easier to scan. #### Density **What it does:** Chooses comfortable or compact spacing for launch actions and context.\ **How to use it:** Use **Comfortable** when you have only a few important actions. Use **Compact** when the screen is a dense internal tool panel.\ **Why / recommended default:** Comfortable spacing makes it harder to click the wrong action in a high-stakes launcher. #### Show timeline **What it does:** Shows related runtime history near the launcher.\ **How to use it:** Turn it on when the audience benefits from recent operational context before launching. Leave it off if the screen should stay clean and action-oriented.\ **Why / recommended default:** Many launchers do fine without much history, but some ops teams appreciate seeing recent runs before they start another one. #### Require claim before action **What it does:** Exists in the shared policy area, but launchers do not use claim behavior in the standard model.\ **How to use it:** Leave it **Off**. Launchers are deliberate action panels, not shared queues.\ **Why / recommended default:** Claim ownership does not add value here and usually just confuses the screen's purpose. ### Available actions ![Annotated builder screenshot: Available actions](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FlkTPP9dbq8cfE7swqBQk%2F04-section-available-actions.jpg?alt=media) This section is the core of the screen. If the action list is empty, the launcher has no reason to exist in the live app. #### Publish announcement **What it does:** Sends an announcement into Notification Center or the configured messaging path.\ **How to use it:** Keep this action when staff need a controlled way to send durable notices. Pair it with well-defined notification categories so the right users receive the right message types.\ **Why / recommended default:** Publish announcement is powerful because it centralizes operational communication. The common mistake is enabling it without clear category policy or audience rules. #### Launch workflow **What it does:** Starts a target workflow manually from the screen.\ **How to use it:** Keep it only for workflows that should be started intentionally by a trusted human. Bind the exact target workflow and test it live.\ **Why / recommended default:** Manual launch is valuable when a process should not auto-run. The common mistake is forgetting to bind the target workflow and ending up with a button that looks ready but cannot start anything. #### After-action screen **What it does:** Routes the user to another screen after an action succeeds.\ **How to use it:** A strong default is **Workflow Status** after launching a workflow so operators can immediately confirm the run started.\ **Why / recommended default:** After-action routing is especially helpful on this screen because users often want immediate feedback after pressing a start button. #### Target workflow **What it does:** Supplies the workflow that **Launch workflow** should start.\ **How to use it:** Choose the exact published workflow for each launch action and retest after any workflow clone or rename.\ **Why / recommended default:** This is one of the most important settings on the screen. Without it, Launch workflow has no destination. ### Preview scenario ![Annotated builder screenshot: Preview scenario](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2Fmt5LsAj2WazsMe0vseOO%2F05-section-preview-scenario.jpg?alt=media) Preview controls help makers verify that the launcher is understandable and safe before it reaches real operators. #### Device and orientation **What it does:** Changes the preview frame across desktop, tablet, and mobile sizes.\ **How to use it:** Always check the primary device your operators use, then check mobile if launches may happen in the field.\ **Why / recommended default:** High-stakes action screens should be easy to read and hard to mis-tap. #### Test persona **What it does:** Simulates the viewer role.\ **How to use it:** Test with the real operator or admin persona, not only with Admin.\ **Why / recommended default:** Role gating is central to launchers, so persona testing catches access problems quickly. #### Preview state **What it does:** Simulates states such as Live, Empty, or Error.\ **How to use it:** Check **Live** for normal action layout and **Empty** to ensure the screen still makes sense when no launch actions are configured.\ **Why / recommended default:** The empty state matters here because it is the direct signal that the screen still needs action configuration. #### Test mode **What it does:** Switches between simulated preview and live runtime testing.\ **How to use it:** Always run at least one live test for Launch workflow and one live test for Publish announcement before publishing the screen.\ **Why / recommended default:** Simulation is not enough for a screen whose main value is side effects. ### 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%2F468uTH23wIVcEwn8EAT1%2F06-section-empty-state-and-sample-data.jpg?alt=media) If the launcher has no configured actions, the empty state needs to make that clear instead of looking broken. #### Empty title **What it does:** Sets the headline shown when no launch actions are configured.\ **How to use it:** Keep the default `No launch actions configured` unless you have a clearer team-specific phrase.\ **Why / recommended default:** The default is direct and accurately describes the problem. #### Empty description **What it does:** Explains what the maker still needs to do for the screen to become useful.\ **How to use it:** Keep or adapt the default `Add workflow or messaging actions to make this screen actionable.`\ **Why / recommended default:** This is one of the rare empty states that is really configuration guidance, so clarity matters. #### Sample item, run, or conversation **What it does:** Provides preview references for screenshots and QA.\ **How to use it:** Use representative workflow and notice examples so you can validate action naming, after-action routing, and supporting context.\ **Why / recommended default:** Better sample data leads to better launch labels and fewer surprises when operators first use the screen. ## Recommended Default Setup | Setting | Recommended value | | --------------------------------- | ------------------------------- | | Listen scope | Entire app or Specific workflow | | Visibility | Operator / Admin only | | Launch workflow → Target workflow | Required for Launch workflow | | After-action screen | Workflow Status | | Payload visibility | Metadata only | ## Common Configuration Patterns ### Manual service request start Launch workflow bound to intake workflow; after-action Workflow Status. ### Ops announcement pad Publish announcement only; Notification Center for readers. ## Testing Checklist * [ ] Launch workflow and confirm a run appears in Workflow Status. * [ ] Publish announcement and confirm Notification Center receives it. * [ ] Confirm a non-operator role cannot see the launcher. ## Troubleshooting ### Launch does nothing Target workflow is not set on the Launch workflow action. ### Empty launcher No actions configured, or actions were removed. ## Best Practices * Configure **Automation Launcher** 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.