Flow: Consolidate All Decision Elements
If you have experience with Process Builder, you would know that the structure is always fixed – You have several nodes and each node returns True or False. To switch that into Flow, you just need to turn those nodes into several Decision elements. However, is that the only way to do so? Is there a way we can consolidate all the easy Decision into one in Flow? Of course there is! In this article, we will show you an interesting workaround that helps us consolidate all Decisions into one.
- Before we start
Please note that this is more of an experiment of how flexible Flow can be. Consolidating Decisions doesn’t provide any better performance. Rather, it just makes your layout look cleaner (In my opinion). If you are a Flow beginner or there is no clear reason of consolidating them, I still recommend using separate Decision elements.
I have a flow like this – I have 4 different sets of criteria to evaluate, together with some actions for each criteria evaluated True. For example, if criteria 1 is true, I want to update Industry field; if criteria 2 is true, I want to update Billing City, etc.
My goal is to consolidate all Decisions into one, instead of having 4 separate Decisions.
I can have only one Decision and combine all the Outcomes in there. Then I create a “fake loop” – whenever the action for each criteria is executed, I link it back to the same Decision. After every criteria is evaluated, I can then link to the final action.
However, the problem is the Decision will always execute the first outcome who returns True. If my criteria 1 is true, the loop will always run the first outcome which then causes an infinite loop, which will be a disaster. How can we avoid this problem? By creating a Number Variable to track which outcomes have been reviewed or executed.
The idea is as such: Create a variable that starts from 0. If the actions from Outcome 1 are executed, update this variable to 1; if actions from Outcome 2 are executed, update it to 2, and so on. This variable will then represents the latest Outcome that has been executed. Since the flow always evaluates the Outcomes in the specified order, all the Outcomes with the order smaller than this variable will have been evaluated or executed. As a result, the flow shouldn’t go through those outcomes again.
To make sure the flow doesn’t do that, in each Outcome condition, we need to add this row:
[Number variable] LESS THAN [Outcome Order]
This way, your fake loop will then run properly. Each outcome actions will only execute maximum 1 time (if criteria met) and minimum 0 time (if criteria not met).
Is it a bit confusing? Check out this example of what would happen in this design:
Which design do you prefer? Like I said, there is no performance benefits if we consolidate the Decisions. Also, the flow will be harder to read or to maintain as it is less straightforward. The only benefit I can think of is the flow looks cleaner if you have too many Decision elements. Do a thorough assessment before you decide which method to use.
Looks awesome Melody!
Good article with clear explanations Thanks Melody
Thanks for the nice words Romaric!😀
What does the update records element look like in this case, since the assignments are not being added to a collection variable?