6.1 Flow Fundamentals & Flow Trigger Types

Flow Fundamentals & Flow Trigger Types

Salesforce Flow is the standard declarative workflow automation engine on the Lightning Platform. With the formal retirement of legacy tools—specifically Workflow Rules and Process Builder—Salesforce Flow serves as the single declarative foundation for implementing complex business logic, guiding user interactions, orchestrating cross-object data operations, and integrating with external systems.

For a Salesforce Platform App Builder, understanding Flow architecture is one of the most heavily weighted domains on the certification exam. An app builder must not only know how to construct flows within Flow Builder, but also possess deep architectural insight into how different flow trigger types execute within the platform's multitenant runtime and governor limit boundaries.

---

Flow Builder Anatomy: Canvas, Toolbox & Elements

Flow Builder is the web-based visual design interface used to build, configure, test, and activate flows. The interface consists of three primary functional zones:

1. The Canvas: The visual workspace where automations are assembled. Flow Builder supports two canvas formats:
   • Auto-Layout (Recommended): Automatically organizes elements, connectors, and branches into a clean, standardized layout. Elements are added via interactive plus (+) icons along the execution path.
   • Free-Form: Allows arbitrary drag-and-drop placement of elements and manual connector drawing, primarily useful for complex legacy migrations.
2. The Toolbox: Located on the left panel, the toolbox contains two tabs:
   • Elements Tab: Displays available building blocks grouped into Interaction, Logic, and Data categories.
   • Manager Tab: Manages all reusable resources, including variables, constants, formulas, text templates, stages, and choice resources.
3. The Button Bar: Provides core administrative controls: Run, Debug, View Tests, Version Details, Activate/Deactivate, Save, and Save As (to create a new flow version or new flow).

The Three Flow Element Categories

Every functional node on the Flow Builder canvas belongs to one of three architectural element categories:

1. Logic Elements

Logic elements evaluate runtime conditions and manipulate in-memory data structures without issuing database transactions:

• Decision: Evaluates conditional logic across multiple outcome paths (equivalent to if / else if / else structures in Apex). Outcomes evaluate sequentially from top to bottom; the first path whose criteria evaluate to TRUE is executed. If no criteria match, execution follows the Default Outcome.
• Assignment: Sets, modifies, adds, or subtracts values from variable resources. When processing record collections, the Assignment element is essential for modifying loop items and appending single records to collection variables (Add operator).
• Loop: Iterates sequentially through a Record Collection or primitive collection variable. Each iteration exposes the current item in memory (currentItem_LoopName), allowing child elements to inspect or transform record values.
• Transform: Declaratively maps, flattens, and reshapes data structures between disparate data sources, such as mapping incoming external REST JSON payloads to native Salesforce sObject records.
• Collection Sort & Collection Filter: Sorts collection variables by field attributes or filters collections down to matching subsets in memory without executing additional database queries.

2. Data Elements (DML & SOQL Abstractions)

Data elements interact directly with the Salesforce database layer. Each data element consumes platform governor limits:

• Get Records: Queries the database using SOQL to retrieve one or more records matching filter criteria. App builders can specify whether to store all matching records (creating a Record Collection Variable) or only the first record, and whether to store all fields automatically or select specific fields.
• Create Records: Inserts one or more records into the database disk (consuming 1 DML statement). Can create a single record using variable values or bulk-insert an entire Record Collection Variable.
• Update Records: Modifies existing records in the database. Can update records identified in a record or collection variable, or dynamically update records meeting specified filter conditions.
• Delete Records: Removes one or more records from the database disk (consuming 1 DML statement). Accepts record variables, collection variables, or explicit filter criteria.

3. Interaction Elements

• Screen: Presents interactive user interface screens in Screen Flows, capturing user inputs, displaying text and tabular data, and rendering reactive components.
• Action: Calls predefined standard platform actions (e.g., Send Email Alert, Post to Chatter, Submit for Approval), external web service callouts (HTTP Callout), or custom Invocable Apex methods (@InvocableMethod).
• Subflow: Calls another active autolaunched flow from within the current flow. Promotes modular architecture, code reusability, and simplified maintenance.

---

Variables, Resources & Global Contexts

Flows rely on Resources—placeholders that store and transform values dynamically throughout the flow lifecycle:

Variable Data Types

• Record: Holds an in-memory sObject instance (e.g., a specific Account, Contact, or custom Invoice__c record) including all its field attributes.
• Record Collection: Holds an ordered list of sObject records (List<sObject>), essential for bulk processing and collection operations.
• Primitive Types: Text, Number (with decimal precision), Currency, Boolean (TRUE/FALSE), Date, Date/Time.
• Apex-Defined: Represents complex custom data objects defined by Apex classes, commonly used for parsing external web service JSON schemas.

Input and Output Availability

Variables have two critical visibility settings on the Manager tab:

• Available for Input: Allows external callers—such as Lightning Record Pages, Quick Actions, Experience Cloud sites, URL parameters, or parent flows—to inject initial values into the variable upon flow launch. For example, capturing the current record ID requires a variable named recordId marked as Available for Input.
• Available for Output: Exposes the variable's final value to calling parent flows, Lightning Web Components, or external APIs after the flow finishes execution.

Global Variables

Flow Builder provides direct access to platform runtime context through system-managed global variables:

• $Record: References the triggering record and its field values in Record-Triggered Flows.
• $Record__Prior: References the triggering record's field values before the current update occurred. Crucial for evaluating whether a specific field changed value ($Record.Status != $Record__Prior.Status).
• $User and $Profile: Contains attributes of the currently running user (e.g., $User.Id, $User.Department, $Profile.Name).
• $Flow: Exposes execution metadata, including $Flow.CurrentDateTime, $Flow.InterviewGuid, and $Flow.FaultMessage (which captures error diagnostics on fault paths).

---

Flow Trigger Types: The Five Core Automations

When creating a new flow, the app builder must select the trigger mechanism that dictates when, where, and how the automation runs:

                                  FLOW TRIGGER TYPES
                                           │
        ┌───────────────────┬──────────────┴───────┬───────────────────┐
        ▼                   ▼                      ▼                   ▼
┌───────────────┐   ┌───────────────┐      ┌───────────────┐   ┌───────────────┐
│Record-Triggered│  │  Screen Flow  │      │Schedule-Trig. │   │Platform Event │
│(Auto on DML)  │   │(User Wizard)  │      │(Time/Batch)   │   │(Event-Driven) │
└───────────────┘   └───────────────┘      └───────────────┘   └───────────────┘
                                    │
                                    ▼
                            ┌───────────────┐
                            │ Autolaunched  │
                            │ (No Trigger)  │
                            └───────────────┘

1. Record-Triggered Flows

• Invocation: Fires automatically in the background whenever an sObject record is created, updated, or deleted.
• Context: Operates in either Fast Field Updates (Before-Save) context (updating fields on the triggering record before database write) or Actions and Related Records (After-Save) context (updating related records, sending emails, or executing asynchronous actions).
• User Interface: Headless automation; contains zero UI or Screen elements.

2. Screen Flows

• Invocation: Initiated manually by a user clicking a Lightning Quick Action button, accessing a tab, navigating to a Lightning App/Record page, opening a Utility Bar item, or visiting an Experience Cloud portal.
• Context: Synchronous user interaction. Supports multi-page forms, conditional field visibility, file uploads, and interactive data tables.
• Execution: Runs in the context of the interacting user, respecting their field-level security and record sharing unless configured otherwise.

3. Schedule-Triggered Flows

• Invocation: Fires automatically at a specified calendar time and recurring frequency (Once, Daily, or Weekly).
• Context: Operates as an asynchronous batch process. The app builder specifies a triggering sObject and filter criteria. Salesforce automatically queries all matching records and creates an individual flow interview for each record, executing in batches of up to 200 records.
• Governance: Executes under the Automated Process system user or default workflow user. Cannot contain Screen elements.

4. Platform Event-Triggered Flows

• Invocation: Fires immediately and asynchronously whenever a specific Platform Event message (EventName__e) is published.
• Context: Ideal for event-driven, decoupled enterprise architectures. Enables Salesforce to react to notifications published by external ERP systems, IoT gateways, or internal Apex microservices without synchronous coupling.

5. Autolaunched Flows (No Trigger)

• Invocation: Has no autonomous trigger. Must be invoked explicitly by an external caller: Apex code (Flow.Interview.FlowName.start()), REST API endpoints, Flow Orchestrator, Invocable Actions, or as Subflows called from parent flows.
• Context: Used to build modular, reusable business utility services (e.g., standardizing tax calculations or generating unique numbering sequences) across multiple applications.

---

Flow Trigger Type Architectural Comparison Matrix

---

Best Practices & Common Exam Traps

Common Exam Traps

• Trap 1: Attempting to pass record context without recordId. When launching a Screen Flow from a Lightning Record Page or Quick Action, Salesforce can pass the current record ID if a variable named exactly recordId (case-sensitive Text variable) is defined and marked as Available for Input.
• Trap 2: Choosing Schedule-Triggered Flows for massive multi-million record volumes. While Schedule-Triggered Flows easily handle tens of thousands of records, processing datasets exceeding 250,000 to millions of records nightly requires Batch Apex (Database.Batchable) to avoid platform timeouts.
• Trap 3: Confusing Platform Event-Triggered Flows with Record-Triggered Flows. Record-Triggered flows respond to standard database sObject DML operations. Platform Event-Triggered flows respond to event messages published on the Salesforce event bus (__e objects), which are event messages rather than ordinary stored records; publish behavior determines whether delivery depends on commit.

Official Source Check

Checked October 19, 2026: Scheduled flow limits and batching.