Screen Flow vs Autolaunched Flow — Key Differences & When to Use Each

Posted by Vinay Vernekar 17th October 2025

Overview

Salesforce Flows are powerful automation tools. Two common flow types are Screen Flows and Autolaunched Flows. Understanding their differences helps you design effective automation: one is for interactive, user-driven processes; the other runs in the background without user interaction.

When to use each

Screen Flow: Use when you need user input or a guided UI—things like multi-step forms, data collection, or guided record updates inside Lightning Experience or Salesforce Mobile App. Autolaunched Flow: Use for background automation such as process calculations, record updates, integrations, or flows invoked by other processes (Process Builder, Apex, REST API, record-triggered flows, or schedule).

Key differences

1. User interaction

Screen Flow: Designed for direct interaction. It contains Screen elements that collect input and present information to users.

Autolaunched Flow: Cannot include screen elements. It runs without any UI and is suitable for automated background tasks.

2. How they are started

Screen Flow: Typically launched from buttons, Quick Actions, Lightning pages, or via utility bar and Experience Cloud pages. Also embeddable in Lightning App Builder.

Autolaunched Flow: Started automatically (record-triggered, schedule-triggered) or invoked by other flows, Apex (Flow.Interview API), Process Builder, or REST API.

3. Execution context and running user

Screen Flow: Executes in the context of the running user (the logged-in user interacting with the flow). Permissions and sharing follow that user.

Autolaunched Flow: Execution context varies—record-triggered autolaunched flows can run in system context or user context depending on configuration (e.g., “Run As” or “System Context Without Sharing” for invocable flows). Be careful about CRUD/FLS enforcement and permission requirements.

4. Interaction with UI and navigation

Screen Flow: Provides navigation (Next, Previous), validation messages, conditional visibility on screen components, and can present dynamic choices.

Autolaunched Flow: No navigation or screens—use decisions, assignments, loops, and actions to process logic. For user notifications, use email alerts, Chatter posts, or Platform Events.

5. Debugging & testing

Screen Flow: Testable in Flow Builder using Debug with input variables and in the UI. Debugging shows screen behavior and user-facing errors.

Autolaunched Flow: Debug in Flow Builder and monitor in Flow Interviews & Setup. Consider adding fault paths and robust error handling since there is no user to correct input.

6. Use cases

Screen Flow examples:

  • Guided account creation with multiple steps and validation
  • Custom approval interfaces or data-entry wizards
  • Survey-style data collection inside Experience Cloud

Autolaunched Flow examples:

  • Automatically update related records when an Opportunity is closed
  • Scheduled data cleanup or aggregation
  • Invocable flows called from Apex or REST for integrations

7. Invoking Autolaunched Flows from Apex (example)

Use Apex to start an autolaunched flow programmatically. Example using the Flow.Interview API:

Map inputs = new Map{'recordId' => myRecordId};
Flow.Interview.My_Autolaunched_Flow flow = new Flow.Interview.My_Autolaunched_Flow(inputs);
flow.start();

Best practices

  • Prefer Screen Flows for guided user tasks and autolaunched flows for background automation.
  • Keep logic reusable: move shared logic into autolaunched flows and call them from Screen Flows when needed.
  • Always handle exceptions and add fault paths for data operations.
  • Be mindful of governor limits—use collections and bulk-safe patterns in autolaunched flows triggered by records.
  • Document who the flow runs as (user vs system) and test with appropriate profiles.

Summary

Screen Flow = user-facing, interactive, UI-driven. Autolaunched Flow = headless, background, and invocable. Choose based on whether you need user interaction, how the flow is triggered, and execution context.