🚀Automation Launcher
Automation Launcher 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 Automation Launcher screen gives authorized users a controlled place to start workflows or operator actions manually from inside the live app.
Think of this screen as a permissioned launchpad for safe manual automation starts. 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 Automation Launcher 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:
A workflow should start on demand rather than only from a form, webhook, or schedule.
Trusted users need a button to run an operational action.
Makers need a controlled manual trigger screen.
You need to prevent users from launching unsafe workflows.
What The Screen Is For
Use Automation Launcher when the user intentionally starts approved automation. It should feel like a small set of safe controls, not a dashboard and not an unbounded workflow list.
Good examples:
Start a manual onboarding workflow.
Run a reconciliation workflow.
Resend a notification after checking context.
Start an escalation process.
Create an internal service request from an operator action.
Bad examples:
A workflow that should always start from a submitted form. Use form trigger.
A scheduled job. Use schedule trigger.
A broad admin dashboard. Use Operator Console.
A task inbox. Use Work Queue.
Unsafe actions for public or untrusted users.
The Mental Model
A Automation Launcher 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 Launch actions section. If the runtime provides workflows, each appears with a Launch workflow button. If not, the screen can still show a Launch configured workflow action based on the configured action target.
A live Automation Launcher screen can show:
Workflow or action name.
Workflow status when available.
Launch workflow button.
Loading state while the launch is running.
Error message if launch fails.
Empty state when no launch actions are configured.
A launcher should never be treated as harmless just because it is a screen. Every launch action should be reviewed for side effects: emails, writes to Notion, status changes, downstream messages, and repeated-run behavior.
Required Foundations And Entitlements
Automation Launcher requires Workflow Foundation when it starts workflows. Messaging Foundation is optional when launch actions publish messages or notify users. Operational screen entitlement is required because this is an operator-style surface.
Operational screen entitlement
Automation Launcher appears in the Operational group.
Workflow Foundation
Launch workflow actions need workflow runtime.
Target workflow
A launch action needs a workflow to start unless runtime supplies launchable workflows.
Strict access rules
Manual launches can have production side effects.
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 Automation Launcher, the maker should name the screen for the user job, not for the internal system. Use names like Start Automation, Operator Actions, Launch Workflow, Manual Tools. 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 Automation Launcher, source binding determines which workflow or context the launcher is tied to. The available action target is equally important because it decides what actually starts.
Entire app
Use for an operator launchpad with multiple safe actions.
Specific screen or form
Use when launch actions are related to one screen context.
Specific workflow
Best default when this screen launches one known workflow.
Conversation or message thread
Use when launch starts a message-driven process.
Linked application
Use when launch starts a linked-app handoff.
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 Automation Launcher, 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:
Finding the target workflow by friendly name.
Selecting after-action screens after launch.
Checking generated recipe workflows.
Confirming hidden operator screens can be opened after action.
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 Automation Launcher:
Restrict to Admin, Operator, Support, or trusted internal roles.
Avoid public access unless the workflow is designed for self-service.
Use allowed users for sensitive launch actions.
Use separate launcher screens for different risk levels.
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 action group.
Operator Actions or Start Automation
Description
Explains what will happen when users launch.
Start approved automation actions from here.
Payload visibility
Usually minimal because launch actions may not show item payloads.
Metadata only.
Density
Controls action card spacing.
Comfortable.
Show timeline
Can show related launch/audit events if available.
On for operators; optional otherwise.
Require claim before action
Not normally relevant.
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.
Launch workflow
launch_workflow
Starts the selected workflow or configured launch action.
Always configure the target workflow intentionally. If repeated launches could create duplicates, make the workflow idempotent or add a confirmation/guardrail outside this screen.
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 Automation Launcher, preview these states before publishing:
Live data, to inspect launchable workflows.
Empty, to verify no launch actions configured copy.
Loading, to verify launch-in-progress state.
Error, to verify failed launch copy.
Admin persona, to confirm operator-only access.
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 Automation Launcher should answer:
Are no actions configured, or is the user not allowed to launch?
Should the user contact an admin?
Does the copy prevent accidental repeated attempts?
Common Configuration Patterns
Automation Launcher is safest when each screen has a small number of clearly named actions.
Single Workflow Start
A trusted user manually starts one workflow.
Recommended configuration:
Listen scope: Specific workflow.
Action target workflow: same workflow.
Visibility: Operator/Admin.
After-action screen: Workflow Status.
Payload visibility: metadata only.
Operator Toolbelt
Operations staff can launch a few approved actions.
Recommended configuration:
Listen scope: Entire app.
Separate actions by business purpose.
Visibility: Operations/Admin.
Timeline: on for audit.
Use clear titles and descriptions.
Manual Escalation Start
A supervisor starts an escalation after reviewing context elsewhere.
Recommended configuration:
Listen scope: Specific workflow or screen.
Target workflow: escalation workflow.
After-action screen: Work Queue or Workflow Status.
Access: Supervisor/Admin.
Testing Checklist
Before publishing or handing this screen to a customer, test the following.
Troubleshooting
Launch button starts the wrong workflow
What it usually means:
The action target workflow is wrong or cloned template binding is stale.
What to check:
Check Available actions target workflow.
Check Template setup state.
Search workflows by friendly name, not copied IDs.
Run provisioning repair after cloning.
Launch fails with an error
What it usually means:
Workflow runtime, entitlement, or target workflow may be unavailable.
What to check:
Confirm Workflow Foundation is enabled.
Confirm target workflow is published/active.
Check Workflow Status or logs.
Confirm user has access.
Users launched too many duplicates
What it usually means:
The launcher allowed repeated starts without workflow idempotency.
What to check:
Add workflow duplicate protection.
Restrict access.
Use after-action routing to status page.
Train makers to avoid public launchers for side-effect-heavy workflows.
Best Practices
Keep launcher actions few and clear.
Use strict access rules.
Explain side effects in the description.
Route users to Workflow Status after launch.
Make target workflows idempotent when possible.
Use staging tests for destructive or external actions.
Recommended Default Setup
Use this as a safe first configuration when the maker is unsure.
Listen scope: Specific workflow.
Target workflow: selected workflow.
Visibility: Admin or Operator role.
Payload visibility: Metadata only.
Show timeline: on for audit.
Require claim before action: off.
After-action screen: Workflow Status.