Flow
Flow is the current Salesforce declarative automation framework, used to build everything from screen-based wizards that guide users through data entry to background processes that fire on record save, scheduled time intervals, or external events.
Definition
Flow is the current Salesforce declarative automation framework, used to build everything from screen-based wizards that guide users through data entry to background processes that fire on record save, scheduled time intervals, or external events. Salesforce introduced Flow in 2012, expanded it through the late 2010s, and made it the strategic automation tool when announcing the deprecation of workflow rules and Process Builder. As of 2026, Flow is the only automation framework where Salesforce accepts net-new declarative builds in production orgs.
A flow is a sequence of elements (Decision, Assignment, Get Records, Create Records, Loop, Screen, Subflow, Call Apex, and several dozen others) connected on a visual canvas. Each flow has a trigger that defines when it runs: a record save, a user clicking a button, a scheduled time, an inbound platform event, or another flow. Flows handle bulk DML, governor limits, and complex branching that the older frameworks struggled with, and they expose every Apex-callable surface to declarative authors. Flow is now the centerpiece of any automation roadmap, and proficiency with it is a baseline expectation for Salesforce administrators and developers alike.
How Flow became Salesforce's automation backbone
Flow types and when each is the right fit
Salesforce supports several flow types, each tuned for a specific trigger. Record-Triggered Flow fires on save events and replaces most workflow rule and Process Builder content. Screen Flow renders interactive forms for users, embedded on pages or launched from buttons. Scheduled Flow runs on a cron-style schedule for batch operations. Platform Event-Triggered Flow reacts to inbound events from external systems or other flows. Autolaunched Flow runs in the background, often invoked from Apex or another flow. Picking the right type is the first design decision, and the wrong choice usually means rebuilding from scratch.
The visual canvas and element library
Flows are built on a drag-and-drop canvas with elements connected by directional arrows. The element library includes data operations (Get, Create, Update, Delete Records), logic (Decision, Assignment, Loop), user interaction (Screen, Action), and integration points (Subflow, Call Apex, Platform Event). Each element has a small set of configurable properties, and the canvas color-codes nodes by category. The canvas reads roughly like a sequence diagram, which makes complex flows tractable for admins who are comfortable with diagramming but not with Apex code.
Bulkification and governor-limit handling
Flows handle bulk DML far better than Process Builder did. A record-triggered flow processing 200 records in one transaction runs the element logic once per record but consolidates DML operations into bulk-friendly batches. This is the engineering win that made Flow the strategic replacement for older frameworks. Loops with DML inside them still produce per-record DML, which hits governor limits fast; the rule is to collect records inside the loop, do DML outside it. Most performance issues in flows trace back to mis-bulkified DML in loops.
Subflows and reusable logic
Subflows let you extract reusable logic into separate flows that other flows invoke. A subflow for "Send Notification to Account Owner" can be called from a record-triggered flow on Opportunity, a screen flow on Case, and a scheduled flow that runs nightly. Subflows take input variables, return output variables, and version independently of their callers. This is the closest declarative equivalent to functions in code, and disciplined teams build a library of subflows for common patterns instead of duplicating logic across dozens of flows.
Error handling and fault paths
Every Flow element can have a Fault path that fires when the element errors (a Get Records returns no rows when one was required, a Create Records fails validation, an Apex action throws). The Fault path connects to error-handling elements: log the failure, send an alert, gracefully degrade. Without explicit fault paths, errors bubble up and either fail the user-facing flow with an unfriendly message or fail the background flow silently. Mature flows always handle the fault paths for every DML element and every Apex call.
Debug, test, and deployment workflow
Flow Builder ships with a Debug pane that runs the flow in sandbox with simulated input data and shows the path through every element along with variable values at each step. This is the primary debugging tool, and it replaces logger statements that developers used to add to Apex. Flows are deployed through change sets, metadata API, or the SFDX tooling stack. Each flow has versions, and the active version is what runs in production; the inactive versions remain available for rollback. Mature deployment practice keeps the previous version active until the new one is validated under production load.
Flow versus Apex: when to switch to code
Flow handles most use cases that Apex used to be required for: cross-object DML, scheduled batch operations, complex branching, callouts via Action subflows. The switch to Apex is appropriate when the logic exceeds Flow's expressiveness (recursive algorithms, complex string manipulation, performance-critical loops on millions of records) or when transaction control needs are finer than Flow exposes. The modern guideline is to start in Flow, switch to Apex when Flow starts feeling fragile or slow, and avoid the dogmatic "Apex for everything" stance that was common in the early 2010s.
How to build and deploy a Flow
Building a flow is part design exercise, part configuration. Pick the trigger type first, sketch the element sequence on paper, then build it in Flow Builder. Test with the Debug pane in sandbox, handle fault paths explicitly, and deploy with proper versioning. The flow that ships to production is almost never the first version you build.
- Decide the flow type
Record-Triggered for save-event automation. Screen Flow for user-facing wizards. Scheduled Flow for nightly or hourly batch operations. Platform Event-Triggered for inbound integrations. Autolaunched for background logic called from other flows or Apex. The flow type is permanent for a given flow, so confirm the choice before opening Flow Builder.
- Sketch the element sequence
Draw the flow on paper or in a diagram tool. List every Get, Decision, Assignment, Create, Update, and Loop with rough names. This sketch catches design issues before you build them in the canvas, where rework is more tedious.
- Open Flow Builder and configure the start element
Setup > Flows > New Flow. Pick the type and configure the trigger conditions. For Record-Triggered Flow, choose the object, the trigger event (create, update, both), and the entry criteria. Set the optimization mode (Fast Field Updates for same-record updates, Actions and Related Records for everything else).
- Build the elements on the canvas
Drag elements from the toolbox onto the canvas, connect them with arrows, and configure each element's properties. Use Decision for branching, Assignment for variable writes, Get/Create/Update/Delete Records for DML. Use Loops sparingly and avoid DML inside them.
- Add fault paths and error handling
For every DML element and every Apex action, drag a Fault path to a logging or notification element. Without explicit fault handling, errors fail the flow with an unfriendly message and no traceability.
- Debug in sandbox with the Debug pane
Click Debug in Flow Builder, supply input variables, and step through the execution. Watch the variable values at each element. Verify that the flow takes the expected path for every scenario, including edge cases like empty inputs and missing related records.
- Activate, deploy, and monitor
Activate the flow in sandbox and run integration tests. Deploy through change set, metadata API, or SFDX. In production, activate the new version while keeping the previous version available for rollback. Monitor via Setup > Paused and Waiting Flow Interviews for stuck instances and the debug logs for runtime errors.
The flow type (Record-Triggered, Screen, Scheduled, etc.) and trigger event. Permanent for a given flow API name.
Used by Apex, other flows, and integrations to invoke this flow. Avoid renaming after dependencies exist.
Each flow has multiple versions. Only one version is active at a time, and the active version is what runs in production.
- DML inside a Loop element produces per-record DML and hits governor limits fast on bulk operations. Collect records inside the loop, then do the DML outside it.
- Fault paths are optional but rarely should be. Without them, errors fail the flow with an unfriendly message and no logged trace, making production issues hard to diagnose.
- Record-Triggered Flow with the wrong optimization mode (Fast Field Updates vs. Actions and Related Records) silently changes behavior. Same-record field updates work in either mode; everything else needs Actions and Related Records.
- Multiple flows on the same object can compound CPU and DML cost during bulk operations. Consolidate into one record-triggered flow per object with internal branching where possible.
- Flow version activation does not migrate paused interviews. Existing interviews stay on the version they started on, so behavior changes only apply to new triggers.
Trust & references
Cross-checked against the following references.
- Flow OverviewSalesforce Help
- Flow TypesSalesforce Help
- Build a FlowSalesforce Help
Straight from the source - Salesforce's reference material on Flow.
- Flow DocumentationSalesforce Help
- Flow Elements ReferenceSalesforce Help
- Order of ExecutionSalesforce Developer
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What type of Salesforce feature is Flow?
Q2. When should you consider using Flow in your Salesforce org?
Q3. What is the main advantage of using Flow over writing Apex code?
Discussion
Loading discussion…