No more ONE Process Builder per Object BS. It doesn’t translate to Flows… so what do we do now?

In a nutshell, here's my rules... Build Flows carefully and with consideration. Don't use Process Builders until the last resort (there are still a few last resorts out there). Similarly for Workflows but they are less evil that Process Builder, and I still use Workflows for Emails. Make liberal use of the new Asynchronous Flow Trigger type coming in Winter '22. Create separate Flows when an After Update is needed on a field that doesn't get updated very often. Create one Flow for Before Save for most Objects and start with doing anything in there, until you can't, or it needs to be split out into Subflows or move to an After Save Context (After Save Subflows in Winter '22 will be great).

For the real advice use the Record-Triggered Automation guidehttps://architect.salesforce.com/design/decision-guides/trigger-automation/

Here’s my advice as I go through moving all my Process Builders to Flows and think about it a bit more.

IN PROGRESS

Bottom Line

• For every flow action, if it can’t be in a Before-Update Flow then think about when this action is required to be run. IF you can set criteria that action does NOT have to be run on every single update, then stick it in a separate Flow with criteria so the Flow is not even run until it needs to. Remember Process Builder ran through almost every node almost every time… that was such a waste of recourses and slowed everything down considerably. If you don’t need to run a Flow, don’t.

Things to Remember

• If two Flows are triggered on the same transaction there is no way of determining which one runs first.

When are things Created

I always like to keep creation and update in separate flows, mainly for ease of updating. Unfortunately without Subflows yet, this rule is a little tricky, so I will probably need to create a few more AfterCreateUpdate flows than I would like.

Eg if you only ever have a Case created via a Web to Case or the API and it always has a Type entered, then there is no need to build a flow to cover the other situation.

Eg I have cases that are created without an Account by the API, and we do a triage process to determine if the case needs to be added to an existing Account or a new Account created.

However, I also have cases that are created when someone phones in and that is often by a known client, to there is an Account ID entered.

So I have to allow for both scenarios for Cases on Create. But for my Update actions nothing happens on the Case except to add the Account ID if it doesn’t need one so I do not need a scenario for Case Update unless it has an Account ID

• CaseBeforeUpdate-HasAccount

• CaseAfterUpdate-HasAccount

• CaseAfterCreate

Always

There is Always going to be an “Always” Flow. This is where you stick the majority of your field updates.

Just create one for each object and add to it whenever you need.

• AccountAfterCreate-Always

• AccountBeforeUpdate-Always

• AccountAfterUpdate-Always (see below)

After Update

It is not recommended to do field updates on After Update, but I will delve into this further as it’s just not going to be possible, but you will need After-Update to do Chatter Posts, Tasks Emails etc.

So, do you do an AfterUpdate-Always Flow and stick decisions in there, or do you do separate AfterUpdate-ACriteria Flows and just do the things required for that criteria.

IT DEPENDS!

And it sucks because we can’t do subflows yet.

• If you have a lot of decisions off one Status then maybe stick it in another flow for clarity (see below for Is Active).

• If there are enough decisions that the flow WILL run every time the record is updated, then stick it in one Always Flow with decision nodes (I’m not sure I will come across this scenario except for where I need to do calculations After-Update).

Is Active

This is the same for any major breaks in the record’s process. Eg when a record becomes Active, Inactive, Closed Won, Closed Lost, etc. Break up your flows into these big statuses because not much that needs to happen on an Open Opp needs to happen on a Closed Lost Opp, or there are the field updates that only need to be updated once a Case is Closed.

Example Naming:

• AccountAfterUpdate-IsActive

• CaseBeforeUpdate-IsClosed

• OpportunityBeforeUpdate-IsWon

Person Accounts

Person Accounts are generally very separate to actual Accounts so I would always keep all flows separate. However you can’t do criteria at the Flow level for Before Create (obviously). So stick a decision node as the first element and check for Person Account (it knows it by then because you have selected a Record Type). Even if you then do nothing with the regular Account and name this AccountBeforeCreate-PersonAccount then it’s still better for long term maintenance. Also name all Flows with the words PersonAccount so you can filter on Person Account related Flows.

Rarely Used Fields

If a field is rarely used or just used once as a set and forget (toggle) type field, then any field updates that happen when this field is set can just go in another Flow. Then they don’t clog up the main Flows that need to be modified more often.

Example Naming:

• AccountBeforeUpdate-IsSpecial

Time Based Flows

If you have a lot of time triggers, then do that all in the one Flow. it’s too hard to lay out Flows well.

Open

Open