Whilst reviewing The Ultimate Guide to Flow Best Practices and Standards from Salesforce, I saw no mention of any design patterns or best practices on how to handle structuring Record Triggered Flows per object, other than this bit:

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.

Separating Flows by business function or role sounds subjective to me, so I don't see how this could be a "good rule of thumb" in all cases.

Since Record Triggered Flows are similar in behavior to Apex triggers, one might think there would be a design pattern or best practice around structuring Record Triggered Flows one per object, or one per object per operation (before create, after create, before update, after update, etc).

Are there generally accepted design patterns or best practices for how to structure Record Triggered Flows per object?

  • 2
    Record-triggered automation on the architect site goes over more information and generally tackles it from the mindset of what you're trying to solve for. Jun 23 at 0:23
  • This is a hard question as a lot depends on your performance requirements. I tend to prefer small flows, ordered by Flow trigger order feature introduced in Spring 22 - but where performance is critical, you'll want to avoid doing DML on the same objects multiple times so flow consolidation can be necessary. It is a balance between modularization, ease of maintenance/understanding, and performance
    – cropredy
    Jun 23 at 9:26


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.