.png){kind=small}
Since Salesforce announced that it will respond to Record Triggered Flows, "Do I need to use multiple flows per SObject or one flow per SObject per context?"
But Spring ’22 is here to answer!
If you ask me before Spring '22, I recommend using one flow per SObject per context. Why is that so? Prior to Spring '22, there was no way to control the execution order when there were multiple record trigger flows on the same object. However, this has not the case since Spring '22.
Set Trigger Order on Flows
In addition, you can control the execution order of records-triggered flows.
With these two features, we can't think of any arguments that strongly support a single-flow approach per object per context.
In addition, there are some other drawbacks for using “Single Flow per object per context” approach.
As the flow grows, the number of running items can reach the 2000 limit.
The flow consumes more memory because all variables created by the flow are active throughout the flow transaction.
Doesn’t go well if you’ve multiple admins/devs on the team.
Salesforce has recommended multiple flows per object since its recent release. It makes a lot of sense to take this approach because you can control the order of the triggers.
If you ask me before Spring '22, I recommend using one flow per SObject per context. Why is that so? Prior to Spring '22, there was no way to control the execution order when there were multiple record trigger flows on the same object. However, this is not the case since Spring '22.
How Flow Trigger Order works?
Flows with the same trigger (pre-save or post-save) for the same object with a trigger order value of 1 to 1000 run in ascending order. Multiple flows with the same trigger sequence value are executed alphabetically based on the flow API name.
Flows without trigger sequence values are then executed in order of creation date. Winter '22 and the pre-run flow and run in this order unless you define a trigger order value.
Flows with a trigger order value of 1001 to 2000 are then executed in ascending order. All bindings are billed using the flow's API name.
The order of the execution in this case would be:
FlowA -> FlowB -> FlowC -> FlowE -> FlowD -> FlowI -> FlowF -> FlowG -> FlowH
Flow Explorer : Gaps and Future
At the moment, the rivers in River Explorer are sorted by label. However, in the future, the order of flow triggers will be associated with the Flow Explorer view, and you will be able to reorder the flows by dragging and dropping.
You can expect to see more coming around this in the future releases.
Hope you find this one useful!
Follow us for more such posts...
コメント