First there was Workflow, and we built separate workflows for each process/action on an Object.
Then there was Process Builder and Flow, and we were advised as a best practice to create a single record-change process per object:
Have only one record-change process per object.
Each time a record is created or updated, all record-change processes for its object are evaluated. We recommend restricting your
org to one record-change process per object. Here’s why.Get a consolidated view of your org’s automation for an object With one consolidated record-change process for an object, you can see
all the criteria that are evaluated each time that object’s records
are updated, as well as the actions that are performed when the
criteria are met.Avoid hitting limits When you consolidate your processes for one object into one master process, you also consolidate the actions in
those processes. With fewer actions, your org is less likely to hit
limits, such as number of SOQL queries.Determine the order of operations If you create multiple record-change processes for an object, Salesforce can’t guarantee the
order in which those processes are evaluated. When you automate
everything in a single process, you explicitly set the order. The
first criteria node is evaluated first, the second criteria node is
evaluated second, and so on.
Now, we have Before-Save Flows which are, effectively, a light version of before triggers.
Per "The Ultimate Guide to Flow Best Practices and Standards":
Keep the amount of Record-Triggered flows per object to a minimum.
While there isn’t really a golden rule, a good rule of thumb is to
separate the flows by either business function or role so that there
is little to no chance of a conflict in the order of execution.
Controlling the order of execution by keeping the amount of flows to a
minimum ensures a consistent outcome for an event in the system.
In my scenario, I am trying to replace 3 Workflow Rules with before-save flows.
- Each of these workflow rules executes before insert/update when
criteria are met - Each has very specific criteria
- Each only does same-record field updates
- It's possible for a single record to meet criteria which would invoke more than one workflow rule
Questions –
- Unless I'm missing something, unlike Process Builder, flows don't appear to have a way to build a decision tree where records are sent to the "next" condition after processing the logic of the last condition. Instead, the Condition element in Flow Builder says that it will "execute the first one whose conditions are met". Is there a way I'm missing that would allow me to combine these 3 workflows into a single before-save flow which conditionally executes different/multiple before-save logic blocks on the list of records?
- Am I oversimplifying this by thinking that multiple before-save flows to replace these existing workflows isn't a huge concern since this is all happening before-save and not creating recursive DML?
- Is the unknown order of execution for the multiple flows the only thing I should be concerned about, and isn't that a pre-existing concern for the workflow rules anyway?
Best Answer
My opinion ..
A: What you have to do is remove the entry criteria for the Before-Save FLOW and replace it with three Decision Elements in the Flow Canvas. You are correct in thinking these are like a before trigger.
A: Since, like triggers, code order is important, you may want one of the before save operations to set values that another before save operation on the same record relies on. Hence, move the logic to the canvas and out of the entry condition
A: True, but with workflows they caused DML to occur and before-save Flows do not