Salesforce Flow Best Practices & Standards Checklist.
This article lists some of the best practices & standards to be followed when creating Salesforce Flows.
- 1. Plan your flow
- 2. Document your flow
- 3. Follow naming conventions
- 4. For each object, use one automation tool
- 5. Keep the amount of record-triggered flows per object to a minimum (one per type)
- 6. Do not hard code values
- 7. Make database changes in the end
- 8. Control when users can navigate backwards
- 9. Frequently save flows
- 10. Check for nulls and empty collections
- 11. Do not use DML statement in a loop
- 12. Choose appropriate flow context
- 13. If possible use before save flows
- 14. Use subflows
- 15. Build a bypass logic in flows
- 16. Use invoked actions for complex logic
- 17. Beware of MIXED DML statement errors
- 18. Large data volumes
- 19. Provide error handler / fault path
- 20. Shield Platform Encryption
- 21. Translation best practices for flows
- 22. Avoid accessing external objects after DML operations in a transaction. To access external data after changing Salesforce data, use scheduled actions
- 23. Test as many permutations of your process as you possibly can
- 24. Salesforce Flow Best Practices Checklist
- 25. Additional Resources
1. Plan your flow
Just as you would do while creating a LWC, plan your flow. Choose appropriate flow type for the scenario whether it would be record-triggered flow or event-triggered. This will save you a lot of rework later on.
2. Document your flow
The way you do for apex code, document your flow. Add appropriate descriptions to various elements so that any admin modifying the flow later would be able to clearly understand what the element is supposed to do.
3. Follow naming conventions
Follow naming conventions for flow, elements and variable names to ensure that the names reflect the purpose of the element.
4. For each object, use one automation tool
If an object has two flows, two Apex triggers, and three workflow rules, you can’t reliably predict the results of a record change.
5. Keep the amount of record-triggered flows per object to a minimum (one per type)
Each time a record is created or updated, all record-change processes for its object are evaluated. Using only one record-triggered flow will help:
- Determine the order of operations – With one consolidated record-change process for an object, you can see all the criteria that are evaluated each time that object’s records are updated, as well as the actions that are performed when the criteria are met.
- Avoid hitting limits – When you consolidate your processes for one object into one master process, you also consolidate the actions in those processes. With fewer actions, your org is less likely to hit limits, such as the number of SOQL queries.
- Get a consolidated view of your org’s automation for an object – If you create multiple record-change processes for an object, Salesforce can’t guarantee the order in which those processes are evaluated. When you automate everything in a single process, you explicitly set the order. The first criteria node is evaluated first, the second criteria node is evaluated second, and so on.
6. Do not hard code values
Never Hardcode Values in Flow. Salesforce record Ids, URLs will change between sandboxes and production which will break the flow. You can use Custom Setting, Custom Metadata, Custom Labels or Get Records element to avoid hard coding.
7. Make database changes in the end
Instead of updating records multiple times in a flow, perform all database operations in the end.
8. Control when users can navigate backwards
If the flow commits changes to the database or performs actions between two screens, don’t let users navigate from the later screen to the previous screen. Otherwise, the flow can make duplicate changes to the database.
9. Frequently save flows
Frequently save flows as you may lose your work due to poor internet connection. Saving the flows also displays any syntax errors in the flows.
10. Check for nulls and empty collections
Always have a decision after a Lookup/Get element to check for no results if you plan on using the results later in your flow. Directly after the Lookup, add an ‘Is null EQUALS False’ decision check for the variable created in the Get element.
Salesforce Flow Best Practices
11. Do not use DML statement in a loop
Using DML statements in a loop may hit governor limits, instead bulkify your flow.
12. Choose appropriate flow context
Flows can run in user or system context. Use appropriate flow context to make sure that flows only access data they are supposed to.
13. If possible use before save flows
If possible use before save flows to update the record that triggered the flow as it offers better performance.
14. Use subflows
Use subflows for any repetitive/reusable logic
15. Build a bypass logic in flows
Just as you would do in case of Apex Triggers, build a bypass logic in flow so that you can bypass them in scenarios where they don’t need to be executed. For Example: Bulk Loading Data.
16. Use invoked actions for complex logic
Flow has its limitations, especially around queries, large data volumes, and working with collections. You can use invoked actions to work around these limitations and harness the power of Apex.
17. Beware of MIXED DML statement errors
You will get Mixed DML Operation Error (MIXED_DML_OPERATION) when you try to perform DML on setup objects(User, User Role), along with DML on other sObjects (non-setup Object such as Account, Contact) (or vice versa) in the same transaction.
18. Large data volumes
Don’t loop over large collections of records that could trigger the Flow element limit (currently 2,000).
19. Provide error handler / fault path
Sometimes a flow doesn’t perform an operation that you configured it to do. By default, the flow shows an error message to the user and emails the admin who created the flow. Create a fault path to handle scenarios when a flow encounters an error.
19.1. Examples of error handling in flows
- Request Corrections from Users
- Display the Error Message
- Create a Case
- Ignore Errors – To bypass errors for a given element in your flow, draw the fault connector to the same element as the normal connector
19.2. Customize the error message for running flow users
As a best practice, it is recommend to display a better message to your user than “An unhandled fault has occurred in this flow”. Do this only if the distribution method you’re using supports flows that contain screens. In other words, don’t do it if your flow is distributed through a process.
19.3. Configure every fault path to send you an email
As a best practice, It is recommend to configure the fault connectors in your flow so that you always receive an email when a flow fails. In the email, include the current values of all your flow’s resources. The resource values can give you insight into why the flow failed.
19.4. Control who receives error emails
When a process or flow interview fails, a detailed error email is sent to the admin who last modified the process or flow. You can choose to send error emails to the Apex exception email recipients.
- From Setup, enter Automation in the Quick Find box, then select Process Automation Settings.
- For Send Process or Flow Error Email to, select who gets the error emails.
- User Who Last Modified the Process or Flow (default)
- Apex Exception Email Recipients – Sends emails to the addresses set on the Apex Exception Email page in Setup.
20. Shield Platform Encryption
You can’t filter or sort records by encrypted fields for the following elements and resources.
- Update Records element
- Delete Records element
- Get Records element
- Record Choice Set resource
21. Translation best practices for flows
- Keep your labels as short as possible. The translated label can’t exceed 1,000 characters (or 255 characters for definition name and version name). If you have a long label for a display text field, consider breaking it up into multiple fields.
- When updating a primary label, check whether it has translations, and update as needed.
- Avoid text templates when translating an email body or other formatted block text.
- Avoid using logic that references translated values.
22. Avoid accessing external objects after DML operations in a transaction. To access external data after changing Salesforce data, use scheduled actions
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 Pause element to an autolaunched flow. If you use a Pause 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.
23. Test as many permutations of your process as you possibly can
Make sure that you test as many possibilities as you can think of before you deploy the process to your production org.
24. Salesforce Flow Best Practices Checklist
You can download the Salesforce Flow Best Practices Checklist and use it when reviewing a flow.
25. Additional Resources
What additional Salesforce Flow best practices & standards do you follow? Please let us know in the comments!