Hello folks,

My posts on Twitter and LinkedIn comparing the two flow decision designs attracted fruitful discussions (see my previous email for reference).

Let’s start by discussing the notable recommendations that came out of this comparison:

• Although this was not the purpose of the exercise, both these flows should have been done as a fast field update. The way they are structured; they don’t do anything other than update the field values on the opportunity that triggered the flow.
• Comparing the decision designs, the one on the right side took advantage of the powerful decision element we have in flow. We can define multiple outcomes tied to criteria, and they will be evaluated from top to bottom.
• Please note that we can define an outcome as the first outcome in the decision element to filter out the records we don’t want to update. Please see the decision element outcome order design below. (To show this path to you in my previous email image, I added an assignment and labeled it “Don’t Do Anything”. Obviously, this is not necessary.)

• One discussion that came out of this was whether we should have multiple update elements after the decision element or use a formula to determine the new value and feed that to one single update element. The formula approach would also eliminate the decision element. I don’t think using multiple update elements impacts performance negatively because they are tied to mutually exclusive conditional outcomes. They don’t ever execute together.
• One observation that was made is that formulas may impact performance negatively. The claim is that the formula value is calculated after every element in the flow. This is an area that I will need to research, as I don’t know the way formulas are evaluated in flow under the hood.

This week was very interesting because Apex Hours published a clear recommendation at this link to only use “One Record Triggered Fow Per Object Per Type” although Salesforce refrains from making such a recommendation. The verdict on this one is still out. The argument on the side of Apex Hours is: “This idea comes 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.” So what Apex Hours recommends is to have one flow or object for before-save and one flow per object for after-save.

The reason Salesforce does not recommend this today is as follows:

You may have multiple flows running on the same object, and you can limit the cases the flows trigger by defining narrow entry criteria (start condition). The specified 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.
In summary, we are still exploring these options, and I personally don’t like to draw clear lines on what can be done and what cannot be done.

If you have questions or comments on this topic, please feel free to go to one of my social channels and write it under a relevant post.

Enjoy

P.S. Originally published on 11/14/2021.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.