Salesforce Flow Best Practices & Standards Checklist

Salesforce Flow Best Practices & Standards Checklist.

This article lists some of the best practices & standards to be followed when creating Salesforce Flows.

Table of Contents

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
- 19.1. Examples of error handling in flows
- 19.2. Customize the error message for running flow users
- 19.3. Configure every fault path to send you an email
- 19.4. Control who receives error emails
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.