As per flow best practices in Salesforce we should create one record triggered flow per object per type/event or context. This idea come from Apex trigger framework. As we can create multiple record trigger flow, but it will be difficult to manage those multiple flows. Better we can create two trigger flow for each object, one for before save operation and one for after save operation. In those before and after trigger flow, we can create decision elements and based on decision result we can call sub flows.
Do not create more than one record Triggered flow on any object per type. Follow below Naming Convention for record trigger flow– <ObjectName><event RType>.
Advantage of one record triggered flow per object
- Creating one Flow per object will enable create reusable Flows and manage all your Flows for a given object in one place.
- When you have just one Flow per object per type, You may hit governor limits – such as number of SOQL queries; furthermore,
- Adding one Flow per object rule will also allow you to avoid generating infinite loops.
- One per object is the only way to enforce order of execution, and if you can’t control that, your troubleshooting will be very difficult.
Step by Step Process for Flow Design Pattern
Let see how we can create Salesforce Flow Design Patterns for “one record triggered flow per object per type/event” with step by step process.
Step 1) Create Record-Triggered Flow
Create record triggered flow and select the before and after event. Don’t add the flow entry criteria so that it will execute every time when record will created or updated. Let take a example for before Account triggered flow. Consider this as your Handler class in Trigger framework.
Step 2) Time to execute the Action.
In flow builder, we need to create a Decision flow element. Add condition for the in decision flow element like below screen
Step 3) Time to add the Action element
Now, Call sub flow or add your flow execution logic like below screen
Step 4) Add more Action
Once your action is done in flow then connect the regular connector from the Update Records flow element to the next decision (i.e. “criteria node”) to execute the next flow.
You might be thinking about this flow will be very big soon. Answer is yes. I highly recommend don’t action element directly here and use Sub-Flow(s) for actions.
Now you may have some question in your mind.
Execute only on Insert?
May be now you have a question if we select the “Trigger the flow when” as “A record is created or updated” then it will execute on insert and update both. But what about if you want to execute some “Decision flow” only on record creation (insert)?
The answer is use
ISNEW() function in your Decision flow element. Create one function like below first
Then use same the same in your “Decision flow element” like below.
NOTE: I also recommenced to use
ISCHANGED() for “Decision flow element” to make sure it will only execute when field value changed. It will avoid extra execution for flow element.
Use Sub Flow
Now you might thinking of you will create only one Trigger flow per object then my flow will be too big very soon. Answer is yes. How we can avoid it ? Now I will recommend to use sub-flow(s) for any logic. Subflows are a sequence of reusable actions that one can use in a Flow.
Creating one Flow per object will enable you to achieve flexibility, create reusable Flows, and manage all your Flows for a given object in one place. Follow Naming convention for that same flow can be reuse. Now Record-Triggered Flow is a great alternative to Process Builder.
If you are new to Salesforce flow then check our FREE Salesforce Flow Training here.