Flow Best Practices

Rule 1: Flow Layouts (Winter ‘21 Release and Beyond)

  • Starting with Winter ‘21 - It is recommended to start using Auto Layout option 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 Fields option 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 {!$Flow.FaultMessage}

  • Fault Connectors are applicable for both ScreenFlow and AutoLaunch Flows.
  • For ScreenFlows - It is expected to provide meaningful Error Message to EndUsers using Screen Components + log the bug using Apex Action.
  • For AutoLaunch and Scheduled Flows - 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 Object Rule (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 Flows to 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 Screen Flows and Scheduled Flows.

Rule 5: Flow Naming convention (Opinionated)

  • Naming Convention Format
    • <ObjectName>_<FlowType>_Run<Before(or)After>_<Created(And/Or)Updated>_<FlowLevel>_<BusinessProcessName>

    • <ObjectType> - Name of sObject in Salesforce
    • <FlowType> - Choose between AutoLaunch, Screen, Scheduled
    • 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: Account_AutoLaunch_RunBefore_CreatedAndUpdated_Main_UpdateRole
  • 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 Flow for 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 Flows can be used.

Rule 7: When to use Lightning Flows vs Code?

  • This document is prepared by Salesforce Platform Team.

Rule 8: Automation Components

Rule 9: Bulkify Flows

  • Wherever possible, please use Record Collection Variables to insert or update data within Flows Loops
  • Please don’t perform DML or CRUD Operations within Loops
  • Please don’t use Legacy Apex Actions as 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.