Flow Builder
Flow Builder is the declarative, point-and-click automation designer in Salesforce Setup.
Definition
Flow Builder is the declarative, point-and-click automation designer in Salesforce Setup. Admins use it to model business logic as a visual sequence of elements that read data, branch on conditions, write back to records, call Apex, hit external systems, and present screens to users. Flows execute on the same multitenant platform that runs Apex, but they require no code.
A single tool produces five flow types: record-triggered, screen, autolaunched, schedule-triggered, and platform-event-triggered. Each saved flow lives under Setup, Flows as a versioned metadata record, and only one version is active at a time. Salesforce retired Workflow Rules in 2026 and is sunsetting Process Builder, so Flow Builder is now the only supported declarative tool for new automation work.
Why every Salesforce admin spends most of their week in Flow Builder
Record-triggered flows, the workhorse type
Record-triggered flows fire when a record is created, updated, deleted, or undeleted on a single object. They run either before-save (fast, in-transaction, limited to same-record updates) or after-save (full element catalog, can hit related records, send platform events, schedule paths). Salesforce recommends moving every Workflow Rule and most Process Builder logic into record-triggered flows, which is why this trigger type accounts for the bulk of new flow creation.
Screen flows for guided user experience
Screen flows render multi-step wizards inside Lightning, Experience Cloud, or a utility bar. Admins drop screens between Get, Create, and Update elements and pass variables forward. They are the answer when a sales rep needs a guided renewal process, or a service agent needs a wrap-up screen at the end of a call. Embed them on a record page with the Flow Lightning component, expose them as a quick action, or launch them from a custom button.
Scheduled and autolaunched paths
Schedule-triggered flows run on a cron-like schedule, query a batch of records, and process each one. They are how admins replace recurring Apex batch jobs without code. Autolaunched flows run without a UI when called from Apex, REST, a platform event, or as a subflow. Both share the same element palette but skip screen elements, since neither has a user sitting in front of them.
Subflows for reusable logic
A subflow lets a parent flow call another flow and pass inputs and outputs. Build a small flow that creates a contact role given an Account ID, then call it from any record-triggered or screen flow that needs it. The parent waits for the subflow to finish before continuing. Subflows are the closest declarative parallel to functions in Apex, and they cut copy-paste maintenance across a busy org.
Debug, fault paths, and error handling
Every flow element supports a fault connector that catches runtime errors and reroutes the path. The Debug tool inside Flow Builder simulates a run with chosen inputs and shows variable state at each step. When a flow fails in production, Salesforce emails the running user or a designated user with the full interview detail. Set the Apex governor for unhandled failures in Setup, Process Automation Settings, so errors do not go to the record owner by default.
Governor limits and bulkification
Flows count against the same governor limits as Apex: 100 SOQL queries, 150 DML statements, and the 10-second CPU ceiling per transaction. A poorly written record-triggered flow that runs DML inside a loop trips the 150-DML limit just as fast as bad Apex would. The standard pattern is Get records, Decision, Assignment inside a loop, then a single Update Records or Create Records at the end. Stay outside the loop for DML and the flow stays bulk-safe.
Migrating from Workflow Rules and Process Builder
Salesforce ships the Migrate to Flow tool for Workflow Rules and is rolling out the same for Process Builder. The tool generates a new flow that mirrors the legacy automation. Always review the generated flow, swap formulas where possible, add fault handling, and run it through Debug before activating. Migration is mandatory because both legacy tools are scheduled for end-of-life, and Salesforce releases will stop creating new ones long before they remove the old.
Build your first record-triggered flow
Flow Builder ships with every edition above Essentials. Open Setup, search Flows, click New Flow, then pick a trigger type. The whole loop, design to activate, takes about an hour for a simple update flow.
- Pick the trigger type
Choose Record-Triggered, Screen, Schedule-Triggered, Platform Event-Triggered, or Autolaunched. The trigger decides the runtime context and which elements appear in the palette.
- Define the entry condition
For record-triggered flows, pick the object, the trigger event (created, updated, created or updated, deleted), and the entry-condition formula. Filtering here is far cheaper than evaluating inside the flow body.
- Drop elements onto the canvas
Add Get Records, Decision, Loop, Assignment, Update Records, Create Records, Action, and Screen elements as the logic requires. Connect them with success and fault connectors. Name every element clearly.
- Test with Debug
Click Debug to simulate a run with synthetic inputs. Inspect variable values at each step and confirm the path matches the expected outcome. Re-test with edge-case inputs, not just the happy path.
- Save and activate the version
Save with a clear version number and description. Only one version is active at a time; activating a new version deactivates the previous one. Inactive versions remain available for rollback.
- Before-save flows cannot call Apex actions, send emails, or hit external systems. Use them only for fast same-record updates.
- Active flows can corrupt data quickly if entry conditions are too loose. Test in a sandbox, deploy via Change Set or DevOps Center, and never edit live in production.
- Recursion is real. A flow that updates the same record can re-fire itself when entry conditions still match. Use ISCHANGED() or prior-value variables to prevent loops.
- The Run As setting decides whose profile evaluates record access. The default of User Who Launched the Flow fails silently when a guest user lacks read on a referenced field.
Trust & references
Cross-checked against the following references.
- Flow BuilderSalesforce Help
- Flow Builder TourSalesforce Help
Straight from the source - Salesforce's reference material on Flow Builder.
- Build Flows with Flow BuilderSalesforce Help
- Visual Workflow Developer GuideSalesforce Developers
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. When should you consider using Flow Builder in your Salesforce org?
Q2. Which Salesforce tool has Salesforce recommended as the future of automation?
Q3. What type of Salesforce feature is Flow Builder?
Discussion
Loading discussion…