Flow Best Practices
Rule 1: Flow Layouts (Winter ‘21 Release and Beyond)
- Starting with Winter ‘21 - It is recommended to start using
Auto Layoutoption when building Flow Solutions.
- This option provides better readability and organization for everyone.
Rule 2: Storing Records in Flows
- For most of our use cases,
Automatically Store all Fieldsoption is recommended.
- Salesforce does lot of optimization behind the scenes. So go ahead and use them without any performance impact.
- In rare cases, we have to manually Assign Variables. This option in my opinion exist only for backward compatibility.
Rule 3: Consider Using Fault Connectors
- For any DML Operations, please consider using Fault Connectors.
- These Fault Connectors should be connected to Custom Exception Log Object (If Applicable or Available in your Salesforce Org).
- This may also need a Reusable Apex Action and will need be created to be used by all Configurators and Developers.
- Fault messages should be logged using available System Variables
- Fault Connectors are applicable for both
ScreenFlows- It is expected to provide meaningful Error Message to EndUsers using Screen Components + log the bug using Apex Action.
ScheduledFlows - It is expected to log the bug using Apex Action.
Rule 4: One Flow Per Object & Sub Flows Usage (Opinionated)
- Given that there are many No-Code Tool options available in Salesforce Platform, we want to design our flows to be manageable in future.
- For most of our use cases, try designing
One Flow Per ObjectRule (Wherever Applicable).
- Although, i see there could be some exceptions to this rule due to the need for Before and Afte Launch Flows because of business requirements.
- What i am getting at is - try to design a flow using `DRY Principles (Do Not Repeat Yourself).
- There is no point in creating 2 BeforeRun flows for a same sObject for a same operation (Say Created)
- When using One Flow per Object, we can also use
Sub Flowsto extend these flows for better organization.
- As a rule of thumb, if a flow contains more than 25 elements, then it is time to think about segmenting business process into Sub-Flow.
- One Flow per Object only applies to
AutoLaunch Flows. It does not apply to
Rule 5: Flow Naming convention (Opinionated)
- Naming Convention Format
<ObjectType>- Name of sObject in Salesforce
<FlowType>- Choose between
Run<Before(or)After>- Represents when Flow runs in given execution context.
<Created(And/Or)Updated>- Represents when Flow runs in given execution context.
<FlowLevel>- MainFlow (or) SubFlow
- Example Flow Name:
- Sometimes, it is necessary to create multiple flows on the same object due to the nature of business requirements and thats ok.
Rule 6: Flow Trigger Configuration
- It is preferred to use
Before Record Save Flowfor all Assignment requirements as it is 10X faster than next LowCode Solution available in Salesforce Platform.
- If DML Operations are necessary on sObject, then
After Save Flowscan be used.
Rule 7: When to use Lightning Flows vs Code?
- Please refer to this document to determine when to use flows and when it is applicable to switch to Apex Code.
- This document is prepared by Salesforce Platform Team.
Rule 8: Automation Components
- Flows are even more powerful when they are extended using
- Automation Components are now officially adopted and supported by Salesforce Platform.
- Before building custom solutions or components in flow, please check for any existing solutions from community.
Rule 9: Bulkify Flows
- Wherever possible, please use
Record Collection Variablesto insert or update data within Flows Loops
- Please don’t perform DML or CRUD Operations within Loops
- Please don’t use
Legacy Apex Actionsas they are not bulkified.
Rule 10: Provide Meaningful Names for Assignments, Flows, Loops, Variables, Decisions etc.
- In this example below, you can see Assignment variables are meaningful to be easily understood by anyone.