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.
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
- 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?