Best practice for migrating from same-record update Process Builders/Workflows to before-save Flows

Question

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.

1. Each of these workflow rules executes before insert/update when criteria are met
2. Each has very specific criteria
3. Each only does same-record field updates
4. It's possible for a single record to meet criteria which would invoke more than one workflow rule

Questions -

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

Answer 1

My opinion ..

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?

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.

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?

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

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

A: True, but with workflows they caused DML to occur and before-save Flows do not

Answer 2

I am also debating these issues as I migrate, but more from a Flow-management/organization perspective. The new Flow Explorer is certainly helpful to give you a bird's eye view of all the Flows on a particular object. If someone else replaces me some day and they want to figure out why something is happening via automation, where will they look? Will they think to look in my singular "before-save" flow for the record, will they look for a Flow specific to the field change? One benefit to the single-Process best practice is that there was one place to look for the automation.