🚀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.
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 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
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
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
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
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
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
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
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
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
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.