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.

The Right Number of Record-Triggered Flows Per Object

“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 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.

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’.

Summary

The general rule of ‘one flow to rule them all’ is partially true. The real magic number when building record-triggered flows is three – one to manage before create or update, one to manage after create or update, and finally, one to manage deletions. The perfect trilogy!

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!

4 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.

Add Comment