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>.
- ContactBeforeSave
- ContactAfterSave
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.
Summery
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.
Thanks for the post. My understanding is that there is no recommendation from Salesforce that says this. Please check and provide a source.
This idea come from Apex trigger framework. One flow per object is the only way to enforce order of execution and if you can’t control that, your troubleshooting will be very difficult and soon you will hit the governor limits.
Thank you for all you do Amit. Great discussion. While it is a very valid recommendation, the beginning of the post sounds like this is a best practice supported by Salesforce, however it is not at this point. That’s what I wanted to point out.
The reason Salesforce does not recommend this today (my understanding) is as follows:
– You may have multiple flows running on the same object, and you can limit the cases the flows trigger by defining a narrow entry criteria (start condition). The defined case criteria can be mutually exclusive. This means that you will be running one flow at a time if you do this right, and even zero flows in some cases.
– As you try and bring all these flow elements in one flow together, you will find yourself in a situation where you run this combined flow on almost every record create/update. However, the real performance gain is achieved when you don’t trigger your flow at all.
– As you build out your flow, you may want to use subflows for repeating logic, and if you do, you must run your combined flow in after-save mode. You will lose the speed and efficiency of the before-save update. Subflows are not available for before-save flows as of today.
@Andy could you elaborate on “As you try and bring all these flow elements in one flow together, you will find yourself in a situation where you run this combined flow on almost every record create/update. However, the real performance gain is achieved when you don’t trigger your flow at all.”
Specially the last part “the real performance gain is achieved when you don’t trigger your flow at all.”
How does this work? When your decisions elements are not met nothing happens right? So how would that impact your performance?
is there a recording about this?
This is a great post but it poses a question about record triggered flows..
I’m creating a record triggered flow to update the opportunity amount field if a budget item is created or updated. The flow loops through all budget items and calculates the total and updates the amount field. If a budget item is deleted, I will also need the flow to loop through and recalculate the total amount. How can I add this piece of the puzzle to the existing flow?
Hi All,
I want to pass $record and $record_Prior variable to Subflow, is there any way to do that ?
Interesting.
However, using multiple Updates in that fashion can lead to exceeded DMLs.
I think it would be difficult to follow this with complicated business logic as it would lead to maintainability issue even with sub-flow
But Flow Trigger Explorer should have resolve the order of execution issue?
The minimum flows per object best practice is changing because of new flow functionality introduced (e.g., flow trigger ordering). Here is a good summary of flow architecture on the Salesforce architect design website: https://architect.salesforce.com/design/decision-guides/trigger-automation/#Tell_us_what_you_think
Interesting enough is the key take away number 5 at the top of the article (which was recently added to this older article after updated due to the new flow functionality introduced):
“Takeaway #5: You don’t need to put all of your record-triggered automation into a single “mega flow” per object, but it’s worth thinking about how to organize and maintain your automation for the long-term.”
Love your posts Amit! Keep up the great work!