Visual Workflow – Best Practices for Using ‘IS CHANGED’ Operator vs. ‘When to Execute Outcome’ Setting

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

The Flow Metadata Documenation lists the various run modes (runInMode)

The context that the flow runs in. Valid values are:

• DefaultMode — How the flow is launched determines whether the flow runs in user context or in system context. In the UI, this value appears as User or System Context—Depends on How Flow is Launched.

• SystemModeWithSharing — The flow respects org-wide default settings, role hierarchies, sharing rules, manual sharing, teams, and territories. But the flow doesn’t respect object permissions, field-level access, or other permissions of the running user. In the UI, this value appears as System Context with Sharing—Enforces Record-Level Access.

The doc seems to be missing the latest addition which is SystemModeWithoutSharing.

However, going off the above and your specific scenario - the warning can be ignored. While it's technically true that the runInMode is mismatched, how the flow is run in default mode determines the context and, in your example (record-triggered), that would be System Mode (as the other answer notes) which matches your subflow's context.

For other situations, this warning may be useful if the flow is being run in a different manner which would cause the resolved contexts to mismatch.