What is Salesforce Flow Builder?
Flow Builder is Salesforce’s primary declarative automation tool. It allows administrators to build complex business logic without writing Apex code. Using a visual drag-and-drop interface, you can automate data updates, send notifications, create records, call external services, and guide users through multi-step processes.
Since Salesforce retired Process Builder and Workflow Rules in favor of Flow Builder (starting with the Spring ‘23 release), it has become the single recommended automation tool for Salesforce administrators. Understanding Flow Builder is now an essential skill for anyone working on the platform.
Types of Flows
Flow Builder supports several flow types, each designed for different use cases:
Screen Flows
Screen Flows are interactive flows that present a user interface. They guide users through a series of screens where they enter data, make selections, or review information. Screen Flows can be embedded in Lightning pages, launched from buttons, or used in Experience Cloud sites.
Common use cases include guided data entry wizards, onboarding forms, and multi-step approval request processes.
Record-Triggered Flows
Record-Triggered Flows execute automatically when a record is created, updated, or deleted. They replace the functionality previously provided by Process Builder and Workflow Rules. You can configure them to run before the record is saved (for field updates and validation) or after the record is saved (for creating related records, sending emails, or calling external systems).
Schedule-Triggered Flows
These flows run on a defined schedule, such as daily or weekly. They are useful for batch operations like sending reminder emails, updating record statuses, or cleaning up stale data.
Autolaunched Flows (No Trigger)
Autolaunched Flows run in the background without user interaction. They can be invoked from other flows, Apex code, REST API calls, or platform events. They are ideal for reusable logic modules that multiple processes need to call.
Building Your First Flow
Here is a practical walkthrough for creating a Record-Triggered Flow that automatically sets the Priority field on a Case based on the Account’s tier:
Step 1: Create the Flow
Navigate to Setup > Flows > New Flow. Select Record-Triggered Flow and choose the Case object. Set the trigger to fire when a record is Created.
Step 2: Add Entry Conditions
Optionally, add conditions to filter which records trigger the flow. For example, you might only want the flow to run when the Case Origin is “Web” or “Email.”
Step 3: Add a Get Records Element
Drag a Get Records element onto the canvas. Configure it to retrieve the Account record associated with the Case using the AccountId field. Store the result in a variable.
Step 4: Add a Decision Element
Add a Decision element to check the Account’s tier. Create outcomes for each tier level:
- If Account Tier equals “Enterprise,” follow the high-priority path
- If Account Tier equals “Professional,” follow the medium-priority path
- Use the default outcome for standard priority
Step 5: Add Update Elements
For each decision path, add an Update Triggering Record element that sets the Case Priority field to the appropriate value (High, Medium, or Low).
Step 6: Activate
Save the flow and click Activate. The flow will now run automatically whenever a new Case is created.
Flow Builder Best Practices
Use Before-Save Flows for Field Updates
When you need to update fields on the triggering record, use a before-save Record-Triggered Flow. Before-save flows do not consume additional DML operations because they modify the record in memory before it is committed to the database. This is significantly more efficient than after-save flows for simple field updates.
Bulkify Your Logic
Flows process records in batches of up to 200. Ensure your flow logic handles multiple records correctly. Avoid placing Get Records or DML elements inside loops when possible. Instead, use collection variables to gather all records first, then perform a single bulk operation outside the loop.
Here is an example of the wrong approach versus the right approach:
Wrong: Loop > Get Records > Update Records (inside loop)
Right: Get Records (before loop) > Loop (process data) > Update Records (after loop)Name Elements Descriptively
Each flow element should have a clear, descriptive name. Instead of “Decision1,” use “Check_Account_Tier.” Instead of “Update1,” use “Set_Priority_High.” This makes flows easier to debug and maintain, especially when multiple administrators work on the same org.
Use Subflows for Reusable Logic
If you find yourself rebuilding the same logic in multiple flows, extract it into an Autolaunched Flow and call it as a subflow. This follows the DRY (Don’t Repeat Yourself) principle and ensures that updates to the logic only need to happen in one place.
Add Fault Paths
Always add fault connectors to elements that can fail, such as Create Records, Update Records, and external service calls. Direct faults to an action that logs the error or notifies an administrator. Without fault handling, failed flow interviews can silently swallow errors.
Tip: Use Custom Notifications or Platform Events in your fault paths to alert administrators immediately when a flow fails in production.
Test with Debug Mode
Before activating a flow, use the Debug button to run it with test data. Debug mode shows you exactly which path the flow takes, what values variables hold at each step, and whether any elements fail. For Record-Triggered Flows, you can simulate the trigger by selecting a specific record.
Governor Limits to Watch
Salesforce enforces governor limits on flow execution. The most common limits to be aware of:
- SOQL queries: 100 per transaction. Each Get Records element consumes one query.
- DML statements: 150 per transaction. Each Create, Update, or Delete element consumes one.
- CPU time: 10,000 milliseconds per synchronous transaction.
- Flow interviews: 50,000 executed elements per transaction.
Hitting these limits will cause the entire transaction to roll back, so designing efficient flows is critical for production reliability.
When to Use Flow Builder vs. Apex
Flow Builder covers the vast majority of automation needs. However, there are scenarios where Apex is more appropriate:
- Complex data transformations that require advanced string parsing or mathematical operations
- Integrations needing fine-grained control over HTTP callouts and error handling
- Performance-critical batch processing with millions of records
- Logic that requires recursive or deeply nested iterations
For most standard business automation, Flow Builder is the recommended approach because it is easier to maintain, does not require a developer to modify, and is automatically upgraded with each Salesforce release.
Frequently Asked Questions
Can I convert my existing Process Builder automations to Flows?
Yes. Salesforce provides a Migrate to Flow tool in Setup that automatically converts many Process Builder processes into equivalent flows. Review the converted flow carefully, as some complex processes may need manual adjustments.
Are flows included in all Salesforce editions?
Flow Builder is available in Enterprise, Performance, Unlimited, and Developer editions. Some features, like screen flows embedded in Experience Cloud, may require additional licenses depending on your edition.
How do I troubleshoot a failed flow?
Check Setup > Flows > Flow Error Emails to see error details. You can also use the Debug mode in Flow Builder to replay the flow with the same input values. For Record-Triggered Flows, review the Apex Jobs page and the debug logs for additional context.