How Many Flows Per Object?

Is One Flow Per Object The Answer?

Apex Hours published a clear recommendation at this link to only use “One Record Triggered Flow 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 the order of execution. If you can’t control that, your troubleshooting will be very difficult, and soon you will hit the governor limits.” So Apex Hours recommends having one flow or object for before-save and one flow per object for after-save.

The Reason for Salesforce’s Recommendation

You may have multiple flows running on the same object. 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 you will be running one flow at a time if you do this right, and sometimes no flows at all.

Combining flow elements may lead to running this unified flow on nearly every record creation or update. However, the real performance gain is achieved when you don’t trigger your flow.

As you build out your flow, you may want to use subflows for repeating logic. 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.

And now we have the Flow Trigger Explorer and the Trigger Order number that support determining the order of execution for your automation.

We are still exploring these options; I don’t like to draw clear lines on what can and cannot be done.

Explore related content:

Flow Tool Kit | Calendar & Scheduling Component

How to Use the Data Table Component in Screen Flow

Migrate to Flow Tips

A Comparative Look at Flow Decision Elements in Salesforce

Error Screen Message Design in Screen Flows