Enhance Salesforce Flows: One Per Object for Clarity
Salesforce we should create one record-triggered flow per object per type/event or context. This idea comes from the Apex trigger framework. As we can create multiple record trigger flows, but it will be difficult to manage those multiple flows. Better we can create two trigger flows for each object, one before the save operation and one after the save operation. In those before and after trigger flows, we can create decision elements and based on decision results we can call subflows.Flows Per Object Limits :
We can create multiple flows on one object but This is complicated when organizations make a big flow that’s supposed to handle everything. You’ve got to perform regression testing on the entire flow after every single update, creating more technical debt. It is not possible in a large amount of complex logic used in flow to create just one record-triggered flow per object – you may have several actions that need to be executed before the database is updated and others that need to be run after. Your record-triggered flows can only run in one of the two contexts, so you may need to create a before flow and an after flow to satisfy your business needs. Suppose record-triggered flows can be triggered either on Create, Update, Create or Update, OR Delete. You can configure your before and after flows to be executed on Create or Update, but Delete will need to be handled separately, etcFlow Trigger Order :
- Flows with the same trigger (before-save or after-save) on the same object with trigger order values from 1 to 1,000 run in ascending order. Multiple flows with the same trigger order value run in alphabetical order based on the flows’ API name.
- Flows without trigger order values run next and in the order of their created dates. Flows in Winter ’22 and before run and continue to run in this order, unless you define a trigger order value for them.
- Flows with trigger order values from 1,001 to 2,000 run next and in ascending order. Any ties are settled using the flows’ API names.
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 the 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.
The disadvantage of one record-triggered flow per object :
- There is a possibility of running into a 2000 elements executed limit as your flow grows.
- Having one flow also consumes more memory since all the variables you create in the flow, live throughout the flow transaction.
- Doesn’t go well if you’ve multiple admins on the team.