How Many Flows Should You Have Per Object?

You may have heard the phrase, “one flow per object”, but is this rule still relevant? Over time, the message has changed. New features have been added that give you more options when making decisions related to your org. When it comes to Salesforce Flow design patterns, there is rarely a straightforward path to the answer – there are many factors to consider, 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. Let’s take a closer look…

Before we dive in, it’s important to remember that every org is different. Even if you’re in the same industry as another business, your Salesforce requirements will be slightly different because your businesses are different from one another. Different Salesforce products and licenses also have different limitations and guidelines when using Salesforce Flow, so keep this in mind when reading the rest of this guide.

The Questions

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 consolidate as much as possible.

One Flow Per Object? Salesforce’s Message

Before we continue, this guide talks specifically about Record-Triggered Flow. Other Flow types, while they may have an impact on records within a certain object, are not inherently tied to them. Record-Triggered Flows are related directly to records of one object at a time and play their part in the order of execution for that object.

Salesforce originally advised that customers should design their automation with “one flow per object”. This was in the early days when Process Builder was still around, and there was only one method of ensuring that your operations took place in the correct order – by structuring them within a single Flow/process. Since the Spring ‘22 release in early 2022 and the introduction of the Trigger Order functionality, the ability to manage the order in which actions occur is no longer restricted to a single Flow.

The confusion grew when Salesforce announced that Process Builder and Workflow Rules would be retired in favor of Flow. Legacy customers who had been around for a long time and hadn’t had much access to Flow before started digging into the different features of the tool and wondering how best to implement it, as the guidance was changing and unclear. 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 from Process Builder and Workflow Rules, but there are also new features and rules to learn when working with Flow. 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 fired up across social media multiple times and one that continues to be of importance and popularity today. Jennifer W. Lee said on the Trailblazer community: “Design according to your business requirements”. This can be a daunting prospect for anyone for whom Salesforce is not their primary responsibility, especially anyone who doesn’t have the right level of admin knowledge or business analysis experience.

Salesforce’s message has become increasingly blurry as they have released tools like Migrate to Flow that create multiple smaller Record-Triggered Flows, one for each legacy automation you previously had. If you have an org with one process per object and five Workflow Rules, this will translate to six new Flows (1 + 5).

This could potentially leave the org with a mess of automations firing off in a random order and doesn’t really guide the users to follow any particular best practice or standard design methodology. Instead, admins are given the power to create Flows and not much guidance on how to maintain them or best manage them without further investigation.

As a result, 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 that some orgs should follow Option 2 and avoid Option 1, but we will get to that).

Option 1: Multiple Smaller Flows with Entry Criteria

The more recent enhancements to the Flow tool lead to an entirely new method of design when 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. That being said, there are pros and cons to this option. There are also reasons why specific businesses should NOT build according to this approach.

Advantages

Ultimately, your Flows are going to be smaller and 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, as not every Flow will be loaded into memory with every single record action, only those where the entry criteria are met.

Disadvantages

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 third-party single-click migration methods), you will need to search and dig through multiple Record-Triggered Flows to figure out where the issue is being caused.

There are also limitations of certain Salesforce licenses that need to be taken into account. For example, Professional and Essentials editions of Salesforce are only allowed five active Flows at any one time. This means if they have an auto-responder email Flow for the Leads object, an auto-responder email Flow for Cases, and a welcome email automation for new Contacts, then there are only two more Record-Triggered Flows that can be created – that’s not a lot! If they wish to automatically trigger an Opportunity record to be created off the back of a Case, a new Enquiry to be created when a Lead is linked to a Property, then they’re all out of Flows (and so lost without them)!

Option 2: The Rule of Three

First, let’s first start by explaining what the ‘rule of three’ means. Remember earlier when we learned that there are three different types of Record-Triggered Flows:

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

This is where the rule of three comes into play – if you are looking to group your Flow functionality together into as few Flows as possible, then you can group it together and slot it in either before your creation/update, after your creation/update, or before your deletion. That being said, you don’t need to create three Flows per object. You should design according to your business requirements.

“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. There is no need to create the other two.
• 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 a delete* Flow for each object.

*Flow can handle deletions, whereas Process Builder can’t. If you’re more experienced in using Process Builder than Flow Builder, this is a key difference between the two.

You can’t actually have one Flow per object like the old Process Builder days. It’s extremely improbable because you are likely to need a before update, an after update, and a delete Flow, which all have to be separate Flows. You can’t just have one Flow that handles all three scenarios and branches accordingly; the Flow will only be triggered in one of the three contexts.

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 in which 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 more feasible and generally preferred approach.

If your business outgrows the rule of three, you should assess this together as a business and plan for a way forward that makes use of the Entry Criteria and Flow Trigger Order.

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 – either before create/update, after create/update, or before delete. Unlike Apex, which can support multiple contexts in a single trigger, a separate Flow is required for each.

Moving from Process Builder to Flow

While the “single trigger condition” (i.e. ONLY before create/update OR after create/update OR before delete) 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’.

Rebuilding and enhancing means a total reassessment of your automation landscape and is bound to require a lot of effort from multiple stakeholders throughout your business.

Creating a Record-Triggered Flow Strategy

As you’ve read, there are two main methods for creating Record-Triggered Flows within your org:

• Option 1 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).
• Option 2 follows the rule of three. This approach is still endorsed by Salesforce themselves in certain circumstances (depending on your license and what your business needs are). It follows a number of best practices that are well-known beyond even the realm of Flow.

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 the rule of three 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.

Summary

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!