How Many Flows Should You Have Per Object?

Share this article...

You may have heard the phrase, “one flow per object,” but is this rule still relevant? Over time, the message has changed. When it comes to Salesforce Flow design patterns, there is rarely a straightforward path to the answer; there are many factors to take into consideration, all in the context of your own org and business processes.

Without sounding too dramatic, is it really a case of one flow to rule them all? This is what we are aiming to unpick – instead of hard rules, we’re giving you ‘rules of thumb’ to guide you on your journey to mastering flows.

There are two questions that often get confused, but should be answered separately when making decisions:

  • How many flows can one object have?
  • How many flows should one object have?

Some people will be seeking the answers to the first question – pause there, as this is the wrong question to ask!

The aim is not to overload each object with as many flows as possible. To maximize your Salesforce org, you need to be smart about how you design each flow, and to consolidate as much as possible.

One Flow Per Object? Salesforce’s Message

Salesforce originally advised that customers should design their automation with “one flow per object”.

Salesforce changed their message when it became apparent that the advice couldn’t be as clear-cut; instead, it had to take the customers’ wider context into consideration. Imagine if Salesforce had said: “Hey, these tools that have been around for a long time, that you built your Salesforce orgs on – they’re not going to work by the end of the year”. That would be a hard pill to swallow.

Not only do customers have to migrate automation across, but there are also new features and rules to learn when working with Flow. I see that Salesforce have taken this into consideration, and therefore, loosened up their messaging.

Technically speaking, it’s not possible to create just one record-triggered flow per object – you may have a number of actions that need to be executed before the database is updated, and others that need to be run after. Your record-triggered flows can only run in one of the two contexts, so you may need to create a before flow and an after flow to satisfy your business needs.

On that same note, record-triggered flows can be triggered either on Create, Update, Create or Update, OR Delete. You can configure your before and after flows to be executed on Create or Update, but Delete will need to be handled separately again. This means that, ultimately, the magic number of flows per object is three:

  • Before create or update
  • After create or update
  • Before delete

It’s a conversation that’s firing up across social media. Jen Lee said on the Trailblazer community: “Design according to your business requirements”. This can be a daunting prospect for anyone where Salesforce is not their primary responsibility, especially anyone who doesn’t have the right level of admin knowledge or business analysis experience.

This being said, Salesforce’s message is becoming increasingly blurry when they release tools like Migrate to Flow that create multiple smaller Record-Triggered Flows, one for each legacy automation you previously had. On top of that, they’ve recently enhanced the new Flow Trigger Explorer tool that makes it much easier to manage multiple Record-Triggered Flows per Object. 

Two main methods of Record-Triggered Flow design have risen from these new tools and the conversation surrounding Flow Best Practices. We’ll go through each in detail, but it will still be down to each individual business to decide which method will serve them best (keeping in mind, there are some orgs that should follow Option 2 and avoid Option 1, but we will get to that).

Option 1: The Rule of Three

“Design according to your business requirements” could mean the following:

  • If you’re a smaller organization, and you can fit it all inside one flow for that object, then do try to fit everything for that object inside one flow.
  • If you’re starting in a fresh org, start with no more than three flows per object – a single before-update, an after-update, and delete* flow for each object.

*Flow can handle deletions whereas Process Builder can’t.

You can’t actually have one flow per object. It’s impossible because you are likely to need a before update, an after update, and delete flow, which all have to be separate flows.

Adding More Flows Per Object

So, you start designing with those foundational three flows per object: the before, after, and the delete. Why would you need more than these for each object?

The situation starts to become complicated where organizations build a ridiculously big flow that’s supposed to handle everything. You’ve got to perform regression testing on the entire flow after every single update, creating more technical debt. You may want to consider splitting the flow. This may feel a little like splitting up the ‘Fellowship’ (of the flows), but it’s a sensible choice at this stage.

At this point, you can make a business decision: “how are we going to split this off?” For example, there may be different business units that will want ownership over their automation, and as the admin, you would liaise with all of these business units.

As of the Spring ‘22 release, you can set the order that record-triggered flows should fire. In a way, “one flow per object” has transitioned to “X per object + suddenly trigger order”. This has helped make multiple flows per object a feasible approach.

Option 2: Multiple Smaller Flows with Entry Criteria

This leads to an entirely new option when designing and building out your Record-Triggered Flows: utilizing the Flow Entry Criteria functionality in conjunction with Flow Trigger Explorer to create multiple smaller Flows that only contain a small amount of functionality, and only a specific set of records will trigger it to run. As with Option 1, there are pros and cons to this option.

The Pros: Ultimately, your Flows are going to be smaller, easier to read, and as a result they will be easier to update if you need to make a change because it will be significantly easier to find the area of the Flow you need to make your changes to. With updates to the Flow Trigger Explorer in the Summer ‘22 release, you can rearrange the order in which your Flows trigger for a specific object much easier due to the new drag-and-drop functionality. The system will also see performance improvements, particularly in orgs with large data volumes.

The Cons: Managing multiple Flows means if you are experiencing a bug, or you have inherited a lot of new Record-Triggered Flows as a result of using the Migrate to Flow tool (or other one click migration method), you will need to search and dig through multiple Record-Triggered Flows to figure out where the issue is being caused.

What You Shouldn’t Do

The Workflow to Flow migration tool goes ‘against the grain’ of having one flow per object. The migration tool creates a one for one – if you’ve got 100 Workflow rules that have existed in Salesforce for a long time, using the migration tool means you’ll suddenly have 100 flows. This isn’t ideal.

For example, if you have 20 Workflow rules that all send email alerts at different stages on the opportunity, and another 30 Workflow rules that update fields on the opportunity, you would be better off creating a single record-triggered flow that encompasses all of this functionality at once. This approach aligns closely with the ‘one flow’ rule, and also gives your business an opportunity to weed out older actions that don’t make sense anymore and add any new ones in. It’s essentially a ‘rebuild and enhance’ approach, rather than ‘copy and paste’.

Organizations that are most at risk are businesses that have used Salesforce for a long time and/or haven’t had a consistent Salesforce resource. With no one to assess what’s already there, there won’t be anyone to decide on the best way to redesign it.

What they’d probably do is use the migrate tool – one button click, and everything migrates across. So, migrate to flow, and away you go! You’ve suddenly got hundreds of flows where actually maybe four or five flows could do the job.

Remodeling Salesforce Automation into Flows

Some thought is required – whether you’re building new flows, or moving other types of automation across to flow. You’ve got to plan with the long term in mind, rather than building flows that solve the requirement you have right now, but won’t be able to accommodate future requirements.

It also depends on the history of your Salesforce org. For example, if you are going straight from Workflow to Flow, you will be further behind than organizations that have been using Process Builder or Apex.

One of the key messages circulating (circa 2017) was to consolidate Workflow rules into Process Builder, so organizations that have been using Process Builder have inevitably had that front of mind. In other words, looking at your Workflow rules and thinking, “Okay, maybe I can group these together into one process”. This would leave you with two Process Builders per object – one for “create” and one for “update”. Or it could even leave you with a single process that had criteria to check whether the current transaction was being executed against a new or an existing record (ISNEW or ISCHANGED).

With Apex, one trigger per object is recommended because, from a technical standpoint, inside of an Apex trigger, you can handle “before”, “after”, “insert”, “create”, and “delete”. You’re able to contain these within a single trigger and separate them – for example, if before insert, then hand off here, if after insert handoff, then handoff there.

Salesforce have recently performed some enhancements to the structure of flows; they have allowed admins and developers to set a lot more of the key properties from within the Start Element (the green element at the beginning of all flows, containing key information about the Flow and how it should begin).

So if you want to have both a “before” create or update, and an “after” create or update, you can’t handle these both inside the same flow. You’ll also need a separate flow to handle deleted records, but remember that delete flows are always run before with no option to run after.

The way that the Flow Builder has been designed means that each flow starts with one single trigger condition.

Moving from Process Builder to Flow

While the “single trigger condition” is similar to Process Builder, you couldn’t separate “befores” and “afters”, whereas you can in Flow – a feature that adds a huge amount of value. For now, I’d recommend the ‘rebuild and enhance’ approach, rather than using Salesforce’s (eventual) migration tool to ‘copy and paste’.

Creating a Record-Triggered Flow Strategy

As you’ve read, there are two main methods to creating Record-Triggered Flows within your org: Option 1 follows the Rule of Three (this approach is still endorsed by Salesforce themselves, and follows a number of best practices that are well known beyond even the realm of Flow). Option 2 utilizes the Entry Criteria and Flow Trigger Explorer to make it easier to manage multiple smaller Flows, which will lead to performance improvements (particularly in orgs with large data volumes).

Your business will need to assess what the best approach is for your specific use case when deciding which approach you are going to use. Ideally, you should stick to just one of these options so that other Flow Developers who work on your org in the future don’t get justifiably frustrated. If your business is going to follow Option 1 for Accounts and Contacts, do it for Opportunities, Cases, and Custom Objects as well. If you’re planning to create multiple smaller Flows that only intake a subset of information, don’t also have a ‘main Flow’ that holds a majority of the Flow functionality for an object. Keep your designs uniform across the board.


If you can, you should take this time as a business to clean up and consolidate your automations. Figure out the automated actions that are really important for your business, and remove anything that is no longer necessary. Build your record-triggered flows in such a way that updating them in the future will be much easier.

If your business doesn’t have the resources to invest time and money into remodeling, that’s okay too. Do the best you can when using the Migrate to Flow tool. If you see any Workflow rules that are performing irrelevant or unnecessary actions, maybe it’s best not to migrate them to Flow. Remember, bad data in means bad data out, and the same goes for automations!

11 thoughts on “How Many Flows Should You Have Per Object?

  1. You could also leverage flow orchestrator to assist with some of these decisions – this would allow a trigger call orchestration and allow branching and stages to call the appropriate flows –

  2. This approach of compiling multiple business requirements into a few flows per object can work for objects with smaller data volumes (<1 million records per object). However, in a Large Data Volume org this design approach wouldn’t take advantage of one of the key advantages of Flow, which is to use Entry Conditions (e.g., IsWon = TRUE) as a way to control whether the flow is loaded into the transaction memory or not.

    Having a few flows with little to no entry conditions would make the flow get loaded into the transaction memory for every record insert/update whether it is relevant or not (just like Process Builder does). So, in an LDV-org it could improve system performance to have more flows per object, but with Entry Conditions to decide whether to trigger it or not.

    1. This is what I have understood to be the best performing architecture when it comes to record save processing time.

  3. This is a fine “goal”. But for objects that have a LOT of field update workflows (one object on our system has over 200), it wouldn’t be manageable to have all 200 in a giant flow. For that reason, I think it should be however many is managable. Maybe even group them by RecordType if necessary. So maybe you have 15 in one flow, but 18 in another with RecordType the first compare and therefore it wouldn’t even fire.

  4. While one BEFORE and one AFTER is ideal (not counting screen or scheduled flows), when you have complicated objects like we do for Case (over 200 workflows), one is just not manageable. My thinking is 10 actions or so per flow, or better yet, break them up by some attribute such as RecordType to make that the first compare. Then subsequent flows won’t waste time being evaluated once it hits the one that is appropriate.

  5. I started looking into this question because I am working on migrating some of my Orgs Process Builder processes over to flow. Some previous admin set up “one process to rule them all” and my initial impression was that it would waste resources running all 10 decisions against every Opp edit made in our org….But, I think the guidelines you lay out in this post make sense — keep it simple, ~three flows/object until we outgrow that.

    I also think there is a benefit from a readability standpoint — minimizing the number of flows makes it easier for future Admins or support to understand your business logic.

  6. If we follow 3 flow per object for after,before and delete we will be required more flow per object because if you consider after flow there we will be having After create,After create or update, after delete like these for before flow as well so will be needing more flows per object,

  7. It seems applicable only for record triggered flows ? What about scheduled flows , flows with scheduled paths and screen flows ?

Add Comment