Study guide
6.3 Screen Flows & Guided User Interactions
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
6.3 Screen Flows & Guided User Interactions
Key Takeaways Explain This Topic AI
Screen Flows deliver declarative, responsive user interface wizards for guided data entry, customer intake, and multi-step business transactions.
Screen input validation formulas require the expression to evaluate to TRUE when data is VALID, the exact inverse of standard object validation rules.
Reactive Screen Components dynamically recalculate and refresh UI elements on the same screen without requiring the user to advance to the next step.
Choice resources include Static Choices, Picklist Choice Sets (inheriting schema values), and Record Choice Sets (dynamically querying sObject records).
Screen Flows can be distributed via Lightning Record Pages, Quick Actions, Utility Bars, Experience Cloud sites, or custom URL parameters.
Last updated: October 2026
Screen Flows & Guided User Interactions
While Record-Triggered Flows automate backend data operations silently, Screen Flows provide the visual presentation layer for declarative automation. A Screen Flow is an interactive user interface wizard that guides internal employees, call center agents, or external community users through structured business processes.
By replacing cluttered page layouts with multi-step guided workflows, Screen Flows enforce data integrity, reduce user training requirements, dynamically display fields based on prior responses, and streamline complex record creation.
Screen Elements & UI Component Architecture
Inside Flow Builder, the Screen Element defines a single visual page presented to the user. App builders assemble screens by dragging standard and custom components from the component pane onto the screen canvas.
1. Standard Input Fields
Screen Flows support a rich variety of native input components that automatically validate format and type:
Text & Long Text Area: Captures alphanumeric strings.
Number & Currency: Captures numerical data with defined decimal precision and currency formatting.
Date & Date/Time: Provides interactive calendar date pickers.
Checkbox & Toggle: Captures boolean true/false states.
Slider: Provides a visual slider bar for numeric ranges (e.g., customer satisfaction rating from 1 to 10).
Address, Email, Phone, URL: Pre-built composite inputs enforcing standard formatting.
2. Selection & Choice Components
Selection components allow users to choose from predefined options: Radio Buttons, Dropdown Picklists, Multi-Select Picklists, and Checkbox Groups. These components are populated using Choice Resources :
Choice Resource Type Data Source Architectural Behavior Maintenance Impact
Static Choice Manually entered in Flow Builder Fixed label and stored value defined directly within the flow metadata High: adding or editing values requires editing and activating a new flow version
Picklist Choice Set Existing sObject picklist field Dynamically inherits active picklist values and translations directly from the object's schema Zero: adding a picklist value in Object Manager immediately appears in the flow
Record Choice Set Dynamic database SOQL query Queries database records matching filter criteria at runtime (e.g., all active Contacts for an Account) Low: automatically reflects real-time database records and relationships
3. Advanced Presentation Components
Data Table: Renders a collection of sObject records in a sortable, columnar grid. Users can view record attributes and select one (single-row selection) or multiple records (multi-row selection). The component outputs the user's selection into a record or collection variable for immediate downstream processing.
File Upload: Enables users to upload attachments directly from the screen. By binding the component's Related Record ID property to a record ID variable, uploaded files are automatically associated with the target record via ContentDocumentLink records.
Display Text: Displays read-only instructional copy, formatted warnings, image graphics, or dynamically merged field values ( {!Account.Name} ) to guide the user.
Section Component: Organizes screen inputs into responsive multi-column layouts (up to 4 columns) with configurable column widths, creating visually appealing, compact forms.
Reactive Screen Components
Historically, Screen Flows required users to click a "Next" navigation button to submit field inputs to the flow engine before subsequent fields or calculations could update.
Reactive Screen Components revolutionize Screen Flow UX by enabling components on the same screen to react to changes in other components in real time without screen transitions:
Dynamic Calculations: A Currency input can feed a formula resource that instantly recalculates and displays estimated monthly payments on the exact same screen as the user types.
Component-to-Component Reactivity: Selecting an Account row in a Data Table component can instantly filter and populate a secondary Data Table displaying related Contacts on the same screen.
Reactivity Support: Supported by standard inputs, formula resources, Data Tables, and custom Lightning Web Components (LWCs) configured with reactive properties.
Screen Component Input Validation: The Polarity Rule
Input components in Flow Builder feature a Validate property that prevents users from submitting invalid data. This feature is heavily tested on the Platform App Builder exam.
The Golden Polarity Rule of Flow Validation
Important
Flow Validation Polarity vs. Object Validation Rules:
In a Standard Object Validation Rule , the error condition formula must evaluate to TRUE when the data is INVALID (i.e., "trigger the error if TRUE").
In a Flow Screen Component Validate Formula , the formula must evaluate to TRUE when the data is VALID (i.e., "allow the user to proceed if TRUE")!
If an app builder wants to validate that a numeric field Discount_Percentage does not exceed 20% (0.20):
- Object Validation Rule Formula: Discount_Percentage__c > 0.20 (Triggers error when exceeded)
- Flow Screen Validate Formula: {!Discount_Percentage} <= 0.20 (Valid when 20% or less)
If the Flow Screen formula evaluates to FALSE , the screen displays the configured Error Message directly beneath the component and prevents the user from clicking "Next".
Conditional Field Visibility
To prevent overwhelming users with unnecessary questions, Screen Flows support Conditional Field Visibility on individual inputs, display text blocks, and entire section containers:
Visibility Rules: Components can be dynamically shown or hidden based on record field values, user profile attributes, or prior inputs on the same screen.
Criteria Logic: Supports All Conditions Are Met (AND) , Any Condition Is Met (OR) , or Custom Logic expressions (e.g., 1 AND (2 OR 3) ).
Example: An intake screen contains a radio button "Has Co-Signer?". The "Co-Signer Details" section is configured to be visible only when {!Has_Co_Signer} Equals 'Yes' . When set to 'No', the section remains completely hidden.
Screen Flow Distribution Channels
Once a Screen Flow is built and activated, it must be distributed to end users. Salesforce provides five primary distribution mechanisms:
Distribution Channel Placement & User Experience Context Passing Mechanism Optimal Business Use Case
Lightning Record Page Embedded directly into the record page layout as a visible component Select Pass record ID into this variable for the Text input recordId Standardized intake forms, continuous checklist completion, embedded calculators
Lightning Quick Action Modal popup overlay launched from page header or highlights panel Automatically injects current record ID into recordId input variable Focused, transactional tasks: Log a Call, Create RMA, Request Escalation
Utility Bar Docked footer drawer accessible across all pages in a Lightning Console app Requires user to search or provide record context manually Global cross-functional tools: Phone dialers, rapid lead creation, internal helpdesk tickets
Experience Cloud Site Embedded on public or authenticated digital experience portal pages Context passed via URL parameters or logged-in user profile Customer self-service portals, partner warranty registration, public event signups
Custom URL / Button / Link Launched via direct web hyperlink ( /flow/Flow_Name?recordId={!Case.Id} ) Parameters appended directly to URL query string Email hyperlinks, custom detail page links, third-party portal launches
Best Practices & Common Exam Traps
Tip
Lightning Quick Actions for High-Frequency Tasks: Instead of embedding large Screen Flows directly on record pages where they take up permanent visual real estate, deploy them as Lightning Quick Actions. This keeps the page layout clean while providing an intuitive, focused modal popup.
Note
The recordId Parameter Convention: When embedding a Screen Flow on a Lightning Record Page or launching from a Quick Action, you do not need complex formulas to capture the parent record ID. Create a Text variable named recordId , mark it Available for input, and for an embedded Flow component select Pass record ID into this variable. An object-specific Flow quick action supplies that context automatically.
Common Exam Traps
Trap 1: Reversing the Screen Validation Formula. Writing a screen component validation formula using object validation logic (evaluating to TRUE for error conditions) causes the field to immediately reject all valid entries and accept only invalid data!
Trap 2: Hardcoding Static Choices for Picklists. If an organization already has a standard picklist field on an object, creating Static Choices in Flow Builder is a major maintenance mistake. Always use a Picklist Choice Set so new picklist values added in Setup automatically appear in the flow.
Trap 3: Using Multi-Select Picklists for Complex Filtering. Multi-Select Picklist choice components output selected values as semicolon-delimited strings ( OptionA;OptionB ), making subsequent string parsing and collection iteration cumbersome in Flow Builder. Checkbox Groups can also return semicolon-delimited selections; a Data Table selection provides records/collections suited to downstream record processing.
Transactions and Record-Type Values
Each Screen or Wait boundary can end the current transaction. A later failure does not undo changes committed before an earlier screen. Put error handling around record operations and use Roll Back Records where supported for pending work. A Picklist Choice Set does not automatically filter its values by record type; use supported record-field components with the RecordTypeId set, or explicit choices/filtering when that distinction is required. For percent inputs, document whether users enter 20 or 0.20 and use the same scale in validation.
Official Source Check
Checked October 19, 2026: Screen picklists and record types .