Screen Flows

Why Screen Flows Matter
Screen Flows are one of the most heavily tested topics in the Advanced Process Automation section of the Salesforce Advanced Administrator exam. Since Salesforce retired Workflow Rules and Process Builder in favor of Flow Builder, Flow has become the single declarative automation tool every administrator must master. Screen Flows specifically address the gap between what a standard page layout can do and what a user actually needs: guided, step-by-step data entry, conditional questions, multi-object record creation, and interactive wizards, all built without code. For the exam, you must understand not only how to build them but also when a Screen Flow is the right answer versus another automation tool.

What Is a Screen Flow?
A Screen Flow is a type of Flow that requires user interaction. Unlike Record-Triggered, Schedule-Triggered, Platform Event-Triggered, or Autolaunched Flows, a Screen Flow presents one or more Screen elements to a user and waits for input before continuing. Key characteristics include:
- It is launched by a user, not by a record change or a schedule.
- It can collect input, display information, and perform logic and data operations between screens.
- It can be placed on Lightning record pages, Home pages, App pages, Utility Bars, Quick Actions, Experience Cloud sites, custom buttons/links, flow-enabled Lightning tabs, and even embedded in Slack.
- It runs in user context by default (respecting the running user's permissions), though you can configure it to run in system context with sharing or system context without sharing.

Core Building Blocks
1. Screen Element
The Screen element is the user-facing step. Each screen can include standard components such as Text, Number, Date, Checkbox, Picklist, Radio Buttons, Multi-Select Picklist, Long Text Area, Display Text, Lookup, Address, Email, Phone, File Upload, Data Table, and Section (for multi-column layouts). You can also add custom Lightning Web Components. Screens support component visibility (conditional display based on earlier inputs) and reactive screens, where one component updates instantly based on another component's value without advancing to a new screen.

2. Logic Elements
- Decision: Branches the flow based on conditions (e.g., if Amount > 10,000 go to approval screen).
- Assignment: Sets or changes variable values.
- Loop: Iterates over a collection of records.
- Collection Sort / Collection Filter: Manipulates record collections without a loop.

3. Data Elements
- Get Records: Queries Salesforce for one or many records.
- Create Records, Update Records, Delete Records: Perform DML operations.
Best practice: place data elements outside of loops to avoid hitting governor limits (the famous "no DML inside a loop" rule).

4. Resources
- Variables: Store single values, records, or collections. Mark them as Available for Input or Available for Output to pass values into or out of the flow.
- recordId: When a Screen Flow is placed on a record page with a text variable named exactly recordId marked Available for Input, Salesforce automatically passes in the current record's ID.
- Formulas, Text Templates, Choices, Record Choice Sets, Picklist Choice Sets, Constants.

5. Subflows and Actions
A Screen Flow can call an Autolaunched Flow as a Subflow for reusable logic, call Apex Actions (invocable methods), send emails, post to Chatter, submit for approval, or call external services via HTTP Callout actions.

How a Screen Flow Works End to End
1. A user clicks a button, action, or tab that launches the flow.
2. The Start element passes control to the first Screen, which collects data.
3. On clicking Next, the flow evaluates Decisions, performs Assignments, and runs Get/Create/Update Records as configured.
4. Additional Screens may display based on branching logic.
5. The flow reaches an End element or the final screen. Users can press Finish, and a Finish behavior can redirect them to the created record, a URL, or back to the original page.
6. If a fault occurs (e.g., validation rule failure), the flow follows the Fault Path if one is configured; otherwise, the user sees an unhandled error. Admins receive a flow error email.

Important Screen Flow Features to Know
- Pause behavior: Screen Flows can allow users to pause and resume later if the flow is configured to allow it and the org setting is enabled; paused flows appear in the Paused Flow Interviews list.
- Navigation control: You can hide the Previous, Pause, or Finish buttons on a screen, or use a custom footer.
- Validation: Screen input components support Validate Input with a formula and a custom error message.
- Stages: Track progress through a multi-step wizard and display progress indicators.
- Transactions: A screen acts as a transaction boundary. DML before a screen is committed when the screen is displayed, so partial data may be saved even if a user abandons the flow later.
- Debugging: Flow Builder includes a Debug tool with the option to run as another user (with permission) and show details of each element executed.
- Versions and Activation: Only one version can be active; changes require Save As New Version and Activate.
- Security: Users need the Run Flows permission or the flow must be granted via profile/permission set when Override default behavior and restrict access to enabled profiles or permission sets is selected.

Screen Flows vs. Other Tools
- Use a Screen Flow when a user must provide input or be guided through steps.
- Use a Record-Triggered Flow when automation should run on save with no user interaction.
- Use a Schedule-Triggered Flow for batch processing at a set time.
- Use an Autolaunched Flow for reusable logic invoked by other flows, Apex, or REST.
- Use Approval Processes for structured multi-step approvals (though a Screen Flow can submit a record for approval).
- Use a Quick Action with predefined fields for very simple single-record creation; choose a Screen Flow when conditional logic or multiple records are needed.

Common Use Cases on the Exam
- A guided "Create Case" wizard that asks different questions based on case type.
- A button on an Opportunity that creates multiple related Contact Roles in one go.
- A call script for service agents, branching based on customer responses.
- A utility bar component that lets sales reps log a call and create a follow-up Task in one screen.
- A Community/Experience Cloud intake form that creates a Lead and related records.

Exam Tips: Answering Questions on Screen Flows
Tip 1 - Look for the words "user input" or "guided." If a scenario says users must enter information, make choices, or be walked through steps, the answer is almost always a Screen Flow. If no user interaction is required, eliminate Screen Flow immediately.

Tip 2 - Know where Screen Flows can be launched. Expect questions about placing a flow on a Lightning record page, a Quick Action, a Utility Bar, an Experience Cloud page, or a custom button. If the question mentions "from the record page without leaving it," think Quick Action or Lightning page component. If it says "always available while navigating," think Utility Bar.

Tip 3 - Remember recordId. A very common question asks how to pass the current record into the flow. The answer: create a Text variable named recordId and mark it Available for Input. Misspelled or incorrectly typed variables are a classic distractor.

Tip 4 - Avoid DML in loops. If a question describes a flow hitting limits or performing poorly, the correct fix is to use Assignment to build a collection inside the loop and then perform a single Create/Update Records after the loop.

Tip 5 - Understand fault handling. When asked how to gracefully handle errors or show users a friendly message, the answer involves adding a Fault Path from a data element to a Screen that displays the error, or sending an email/custom notification.

Tip 6 - Distinguish conditional visibility from Decision elements. If a field should appear on the same screen based on another answer, use component visibility (or reactive screens). If the flow should go to a different screen or path, use a Decision element.

Tip 7 - Know the run context. If users lack access to records the flow must update, consider running the flow in system context without sharing. However, be cautious: exam questions may test that the default is user context and that Screen Flows respect field-level security on screen components.

Tip 8 - Reusability points to Subflows. If multiple flows share the same logic, the best-practice answer is to build an Autolaunched Flow and call it as a Subflow rather than duplicating elements.

Tip 9 - Testing and deployment. Questions about verifying behavior point to the Debug tool, running as another user, or using a sandbox. Remember to activate the new version after changes; forgetting activation is a common cause of "the changes aren't showing" scenarios.

Tip 10 - Eliminate retired tools. If an answer choice suggests Workflow Rules or Process Builder for new automation, treat it as incorrect. Salesforce expects Flow as the modern answer.

Tip 11 - Read for scope creep. If the scenario is simple enough for a Quick Action with predefined values or a validation rule, do not overengineer with a Screen Flow. The exam rewards the simplest declarative solution that fully meets the requirement.

Summary
Screen Flows are interactive, user-driven flows that collect input, apply logic, and manipulate data across multiple objects. Master the Screen element and its components, the Decision/Assignment/Loop logic elements, the Get/Create/Update/Delete data elements, the recordId input variable, fault paths, run context, and the many ways to surface a flow to users. On the exam, identify user interaction as your trigger to choose Screen Flow, apply best practices such as avoiding DML in loops and handling faults, and always prefer the simplest declarative approach that meets the business need.