Automate This! — Tom Hoffman’s ‘One Per Object’ Flow Design Pattern

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by #AwesomeAdmin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, three community Flow experts showcase their record-triggered flow design pattern. This blog post covers the record-triggered flow Tom Hoffman discussed during the episode.

As the Salesforce world transitions to Flow-only automation, the question of the “best” approach has been raised frequently and with different answers. I believe the ideal design pattern for a flow is the one that best fits the needs of your architecture and requirements; however, when you’re getting started, I recommend the One Per (Object) design pattern as the first option.

Beginning with a pattern familiar from Process Builder, the One Per design pattern builds on existing knowledge and allows you to transition to other design patterns if your requirements point you in that direction.

A familiar pattern

Let’s look at the common Trigger-Handler-Class pattern used in Apex design. A record created/updated/deleted causes a trigger to fire. This trigger has no business logic. Instead, it uses a trigger handler (an Apex class) to apply logic and send the record through any additional Apex classes.

Thanks to Jigar Shah for the image!

Now, look at the Process Builder below. It follows the same trigger (navy blue box), controlled delegation (Decision element with business logic), and logic & utility (Immediate Actions) as Apex.

This is the foundation of the One Per design pattern. We apply the same Trigger-Handler-Class pattern from Apex and Process Builder within the framework of Flow, adhering closely to the rules that govern Apex and Process Builder—specifically, the concept of one trigger, per event & order, per object.

Let’s make sure we have a common understanding of the words we’re using. These definitions should keep us aligned:

• Trigger: Conditions that start automation
• Event: A DML Operation, for our purposes, limited to create, update, and delete
• Order: Order of Execution (OoE), where Before Save triggers are #3 in the OoE and After Save triggers are #14
• Object: A standard or custom object in Salesforce

The One Per design pattern defined

At the heart of the One Per design pattern is a simple statement: You should only have one flow, per event & order, per object. With Process Builder, it was possible to have a single process for each object, but the flexibility of flow triggers mean we have to expand the ‘one per’ mantra to capture some additional nuance.

Flows have three triggering events (create, update, delete) AND two places in the OoE—Before Save (#3) and After Save (#14)—so our One Per design pattern states that we should only have one flow trigger per combination of these events & orders. Just like we’ve built with Process Builder, this one trigger per event/order will not have any entry criteria, utilize multiple Decision elements for business logic, and then have actions for each decision (see One Per in Action below for examples).

Possible Flow Triggers in the One Per Design Pattern

The One Per design pattern also uses a standardized naming convention. This allows for consistency with documentation, allows any user to visually understand the flow type and purpose, and allows us to create object automation list views that make navigation simple.

One Per design pattern in action

The One Per pattern takes on the same shape as Process Builder in Flow. Starting with our record trigger, we have no criteria as we’re using our Decision elements as trigger handlers.

Each Decision element holds the business logic and, based on that logic, routes to the appropriate actions before stopping OR continuing on to the next Decision element.

You’ll notice that all of our actions are represented by Subflow and Action elements. With combining automation into this single record-triggered flow and the complexity of that automation, the screen would become quite challenging to read and understand.

To support easy visibility and control, the One Per pattern only uses Subflow and Action elements in After Save flow triggers.

For Before Save triggers, most actions are updates to the record triggering the automation and done using Assignment elements, so having your operations directly in the flow trigger is okay.

After Save triggers tend to be more complex, and the subflow/action only layout creates a clean, simple-to-follow flow trigger.

In addition to the simplified layout, moving actions to subflows allows them to be componentized and reused. See the example where based on the Decision – Sharing is Caring, we call the same subflow three different times (providing different inputs).

The same flow class can be constructed and called from various places based on Decision elements to tightly control your OoE, reduce the number of active flows in your org, and ultimately make your org easier to maintain.

Our foundational pattern is used for Before Save automation, but instead of calling subflows or actions, we use assignments to update values on the record that triggered the flow. We still have no criteria in our trigger and nothing is structurally different, just the type of Action element to the right of our flow trigger ‘handlers’ will typically be assignments.

The other flow example is of an asynchronous flow in the One Per model. Because asynchronous flows require conditions in the logic (same with scheduled paths), they are purpose built, named accordingly, and have all actions directly on the layout; there’s less of a need for the subflow pattern.

Why One Per?

As you’ve noticed, the views on the best flow design pattern vary greatly. While none are wrong, I do believe that the One Per design pattern is the best starting point for the following reasons.

Builds on existing knowledge
The foundation of the One Per model follows the Trigger-Handler-Class pattern familiar to those with experience in Workflow Rules, Process Builder, and Apex. It allows an easy migration from Process Builder since most orgs follow the One Per model.

Where there is a clear delineation, like an entirely new business unit that has completely different record types and processes for their Sales team, it could make sense to split the automation into two groups of flows. However, the rule of having as few triggers as possible per object/event should always apply. In this case, starting from the One Per design pattern, you can clone your existing flow and add/remove elements as needed to start the foundation of your new flow group.

Moving the other direction (many flows to consolidated) is more challenging than going in the opposite direction, which is a key reason I recommend to start One Per until it no longer meets your needs’ approach.

Provides simplified visualizations
Looking at the examples above for Before and After Save triggers, a user can read down through the decisions and subflows/actions and from one screen have an understanding of the OoE, what is happening at each subflow/action, and the associated automation in general.

With multiple flows, while the Flow Trigger Explorer is a wonderful tool, it has limited real estate. Plus, you’ll need to click into each flow separately to see what it’s doing and then also see the details of the flow, any subflows, and actions. Imagine what our After Save example would look like as four separate flows. How much longer would it take you to get an understanding of the Account After Save automation versus this view?

This is another strength of the One Per design pattern and why, until requirements dictate otherwise, it’s an ideal starting place.

Offers advanced control for Order of Execution
Spring ’22 brought the Trigger Order value to the Flow Trigger Explorer, which is a pretty sweet feature to have available. Flow Trigger Explorer only works linearly though, from trigger A to trigger B according to the trigger order.

In the One Per design pattern, based on record values or paths already taken, we have the ability to skip Decision elements and repeat Decision elements, providing an enhanced level of control over the OoE not available with one flow/per start criteria approach.

We still have the full advantage of using Flow Trigger Explorer for moving our asynchronous and scheduled flows into the order we would like before or after our primary record-triggered flow.

Creates consistency
The naming standards for the One Per design pattern brings the language of declarative automation inline with that of our developer peers. This common usage of terms and patterns allows teams to collaborate better and can foster a better conversation around design from both directions.

The approach means flows are all built according to the same standard and method, reducing the effort for documentation, training, and maintenance.

Speaking of maintenance, you can debug from a single Before & After Save flow trigger in the One Per model, making testing and fixing updates involve less steps, screens, and time than other approaches.

Enhances performance
Luke Freeland is a thought leader for Salesforce benchmarking and has done a series of Flow benchmarks and write-ups since 2020 on this topic. In all of his testing, the single flow with multiple Decision elements outperformed the multiple flows with as much as a 3:1 margin. Two of his results are shown below:

In the first, we see that the Ordered Start (Flow Trigger Explorer) multiple flow approach is about 15% faster in his tests; however, the efficiency gain in this sample size and methodology is minimal compared to the gain from multiple flows to single flows in his earlier benchmarking exercises.

Resources

• Salesforce Architects Site: Record-Triggered Automation Guide
• Trailhead: Build Flows with Flow Builder
• External Site: Luke Freeland’s Metillium Blog: Flow Benchmarking Posts
• Salesforce Admins Blog: Automate This! — Designing Record-Triggered Flows