You are here:
Plan for Success with Flow Builder Best Practices
Before you build and distribute flows, plan your approach. To minimize errors and rework, follow these Flow Builder guidelines.
Required Editions
This video explores ways to use Flow Builder to create powerful automations without code.
View this video in a separate tab.
Plan out your flow before you start building.
Write or draw out all the details of your business process. This practice helps you identify the information needed, its source, and the proper logic and actions. Planning simplifies building the corresponding flow.
Document your flows with labels, API names, and descriptions.
Labels, API names, and descriptions are the only way to document what your flow is doing.
Use helpful labels and API names that describe what an element is doing, or what a resource
is holding. For example, Get Account Records for a get records element and
ThreeDaysFromToday for a formula resource that calculates the date that's
three days from today. Use the Description field on elements, resources, and flow versions
to give more detail. For example, for a create records element named Create a
Task, a good description is: Creates a task to follow up with the
triggering contact. The task is assigned to the owner of the contact and is due a week
after the flow runs. The more descriptive your labels, API names, and
descriptions are, the easier it’s to make future updates to your flow.
To find and update resources that are missing descriptions, open the Toolbox panel 
, open Filters 
, and select Missing Description. The results show elements
and resources without descriptions. Review the list and add descriptions as needed.
Build your flows in a test environment—like a sandbox or Developer Edition org.
Build your flows in a separate environment. Avoid accidentally changing records in your production org. Enter fake data and test various versions of your flow without changing or deleting production data.
Start small and build on a successful flow.
To make testing and troubleshooting flow errors easier, don't build the entire flow all at once. Instead, build your flow in small, functional chunks. Building this way makes it easier to find and fix problems as you go, rather than tackling a large, buggy flow at the end. If a problem arises, you know exactly which recent addition caused it, simplifying the fix.
- Start small: Build a flow with just a few elements and get that initial piece of functionality working. Fix any issues before moving on.
- Add and test: After you know that the first chunk works as expected, add the next small piece of functionality. Test the flow again to make sure the new addition works without breaking the existing parts.
- Repeat: Continue adding and testing functionality in small iterations until your flow is complete.
Never hard code Salesforce IDs.
IDs are org-specific, so don’t hard code new or existing IDs. Instead, pass IDs into variables when the flow starts. For example, use merge fields in URL parameters or use the Get Records element to get the ID of an email template.
Wait until the end of the flow to edit the database.
Because flows operate under Apex governor limits, group all database changes together at the end of the flow, whether those changes create, update, or delete records. Also, avoid making edits in a loop path. Instead, use assignment elements in the flow and edit everything all at once after the loop.
Avoid creating records before the first screen in the flow.
Creating records before the first screen can trigger unintended database operations and can create a poor user experience.
Control when running users can navigate back.
If a screen flow changes the database or performs actions between two screens, prevent users from going back to a previous screen. Otherwise, the flow can make duplicate changes to the database.
Provide an error handler.
Sometimes a flow doesn’t perform an operation that you configured it to do. The flow can be missing crucial information, or the running user doesn’t have the required permissions. By default, the flow shows an error message to the user and emails the admin who created the flow. Control that behavior. See Customize What Happens When a Flow Fails for more information and recommendations.
Save early and often.
Sometimes Flow Builder falls victim to unexpected problems, like losing Internet access. Salesforce doesn’t save your changes automatically, so it’s up to you to save your work. Save as often as possible, so that you don’t accidentally lose a few hours’ worth of work.
Restrict data access via profiles and permission sets.
Limit data access to the right flow users. To restrict access to enabled profiles or permission sets, edit the access for a flow from the Flows list view.
Control data access with the Subflow element.
To have a flow respect user permissions for some actions and ignore them for others, use the Subflow element. For example, to respect user permissions for actions, create a flow that runs in user context. To ignore user permissions such as object permissions and field-level access for other actions, create a separate flow that runs in system context. Then, add the Subflow element in the flow that runs in user context to start the flow that runs in system context.
Test as many variations of your flow as possible.
Test your flow thoroughly, especially if it uses branching or complex logic. Test as many scenarios as possible before distributing the flow.
Avoid accessing external objects after Data Manipulation Language (DML) operations in a transaction.
If Salesforce creates, updates, or deletes data in your org and then accesses external data in the same transaction, an error occurs. In your flow, we recommend using a separate transaction to access data in an external system. To do so, end the prior transaction by adding a screen or local action to a screen flow or a Wait element to an autolaunched flow. If you use a Wait element, don't use a record-based resume time.
For example, a screen flow creates a contact and then displays a confirmation screen. Next, the flow updates the contact in the external system. The flow doesn’t fail because it uses a separate transaction to access the external data.
Avoid mixing Apex DML operations across object types in a transaction.
A single transaction can’t mix Apex DML operations on objects such as Account, Setup objects such as User Role, and external objects. For example, if Salesforce updates an account and a user role in a single transaction, an error occurs.
Use a separate transaction instead. To end a transaction, add a screen or local action to a screen flow or a Wait element to an autolaunched flow. If you use a Wait element, don't use a record-based resume time.
Avoid custom CSS.
Use custom CSS sparingly and avoid targeting DOM elements in components that you don’t own. Changes to a component’s internal DOM structure are likely to break hard-coded CSS selectors. Salesforce can change the internal implementation of Salesforce components at any time. Also, Salesforce Customer Support can’t help resolve issues with custom CSS.
Optimize performance with Apex debug logs.
The Apex debug logs provide detailed information about the execution of a flow, including the values of variables and the actions taken at each step. To optimize flow performance such as CPU consumption, analyze the Apex debug log for:
- The FLOW_CREATE_INTERVIEW_BEGIN event name that shows each flow that started, including the flow API name and ID.
- The FLOW_START_INTERVIEWS_BEGIN event that shows each interview that’s running for a flow.
- The FLOW_ELEMENT_LIMIT_USAGE event that shows CPU time consumption for each flow element that runs in a flow.
