A Screen Flow runs in the user’s browser, showing one or more screens that collect input and respond to clicks. An Autolaunched Flow runs entirely in the background — no UI — invoked by Apex, REST, a Lightning button, a subflow, or other automation. Same flow engine, different invocation model.
At a glance
| Screen Flow | Autolaunched Flow | |
|---|---|---|
| Has UI | Yes — at least one Screen element | No — purely background |
| Triggered by | User opens a button, URL, Lightning page, app page, community page | Apex, REST, subflow, Quick Action, Process Builder, Record-Triggered Flow’s subflow call |
| Can use Screen elements | Yes | No (compiler blocks them) |
| Can pause for user input | Yes | No |
| Can be called from another flow | As a subflow with no UI propagation (rare; usually you split UI off) | Yes — common subflow pattern |
| Typical run time | Seconds (user is waiting) | Milliseconds to seconds |
| Failure handling | User sees an error | Caller (Apex/REST) sees the error |
Concrete examples
Screen Flow
- A 3-step case creation wizard that asks for issue type → severity → description
- A community self-service form that creates a Lead and shows a thank-you screen
- An internal admin tool to bulk-clean records with confirmation steps
Autolaunched Flow
- A subflow called from a Record-Triggered Flow to send a standardised email
- An Apex-callable flow that computes a discount for a Quote line
- A Quick Action flow that runs in the background when the user clicks a button (with no follow-up UI)
- A REST API endpoint flow that an external system calls
Common confusion
A Screen Flow has at least one Screen element. The moment you delete every Screen, you can convert it to Autolaunched. Until then, you can’t — the type is set when you create the flow and changing later means re-saving with a different type setting.
Calling between types
Autolaunched flows can be called as subflows from anywhere — including Screen Flows. The reverse is not clean: you can’t easily embed a Screen Flow inside an Autolaunched Flow because the Autolaunched parent has no UI surface to render the child’s screen on.
If you need a UI somewhere in a primarily-background process, you typically split the process into two flows and connect them with Approval or Wait elements.
What about Record-Triggered, Schedule-Triggered, Platform Event-Triggered?
Those are separate flow types — they’re like autolaunched flows but with their own trigger source. None of them can show screens.
What interviewers want
- The core difference: Screen Flow has UI, Autolaunched does not
- The invocation difference: user-initiated vs system-initiated
- Bonus: that autolaunched flows can be subflows of screen flows (and vice versa with restrictions)
Related
- How many types of flow are there?
- What is a Flow?
Verified against: Salesforce Help — Flow Types. Last reviewed 2026-05-17 for Spring ‘26 release.