Automate This! — Designing Record-Triggered Flows

An automation topic that’s very top of mind for admins involves the question, “What’s the right record-triggered flow design pattern to use?”

Background

For years, Salesforce promoted a ‘one process per object’ automation design pattern when automating record-triggers in Process Builder. However, as we began to interview customers and partners in preparation to Go with the Flow, we heard repeatedly that this pattern was limiting and challenging from an organizational standpoint. We also spoke with our engineers and our Support team, and found that this pattern also often ran into performance and maintenance problems.

It became clear that while ‘one process per object’ was working for some of our admins, it was not sufficient to meet everyone’s needs. There were a few common reasons why:

Ownership and organization: Complex organizations may have different owners for different automation, particularly on what we like to call “overloaded objects” (those few key objects in your org, like Account, Case, and Opportunity, that get the bulk of the automation from different teams in one organization). Automation may also be installed from the AppExchange or other solution consultants.

Ordering: The only way to order processes in Process Builder or Workflow Rules was to combine things into one process. Admins have been asking for this to be controllable for years!

Performance: Depending on the characteristics of your organization, it can be most performant to group like-operations together. This can ensure you have the speediest transaction possible.

So, we went back to the drawing board when envisioning what this experience would look like in Flow. And I do mean a literal drawing board in this case. We wanted Flow to offer a more flexible set of tools to address these problems.

Presenting Flow Trigger Explorer!

The result of those brainstorming sessions was Flow Trigger Explorer. With Flow Trigger Explorer, you’re able to see all of your record-triggered automation in one place. It gives you a birds-eye view into all of the flows that might already be running on an object. So, if you want to make a change to one of those “overloaded objects,” you know where to start.

We’ve added Flow Trigger Explorer in several places—you can get to it from your individual flow, from the main Flows list view, and even from Object Manager.

With Flow Trigger Explorer, you can also order your flows! You can change their order individually or rearrange them using drag-and-drop.

Performance and other considerations

When it came to questions of performance, the solution was and continues to be more complicated (isn’t performance always the most complex problem?). We found that combining or separating flows wasn’t the real source of most performance problems.

Instead, we found that using the following features of Flow can help address many common challenges:

1. The vast majority of record-triggered automation is updating another field on the triggering record. We have mega-optimized for this use case with Fast Field Updates (also called before-save flows). Put all your same-record updates there for up to 10x faster performance.
2. For all other use cases involving accessing or writing data (think of all the other times you use a pink Data element in Flow), be judicious. If you find yourself updating the same related record in five different flows, you’ll see worse performance than if you combined those into one flow with several Decisions leading to a single record update.
3. For callouts to external system or long-running operations, try using our Run Asynchronously path. This has more relaxed limits.
4. Finally, the fastest flow of all is one that doesn’t have to run at all! Use Entry Conditions as much as possible to try to only call a flow when a relevant update or change has happened. The majority of those ‘one process per object’ process builders still end up running no automation at all on an individual change. You can use Entry Conditions in Flow to make sure that never happens.

It’s up to you

So, what’s Salesforce’s official new best practice for record-triggered flows? Do what’s best for your organization! Now, some may find that generous, but others may find it frustrating. It’s more ambiguous than ‘one flow per object.’ But it’s always our goal to have the platform match the way you work, instead of forcing you to work to match the limitations of our platform. If a parent record-triggered flow with lots of subflows works for you, then go right ahead and keep using it. If you’re struggling with some of the things we’ve mentioned above, why not try a different approach? Break out your same-record updates, try to silo by business unit or process stage using Entry Conditions, or otherwise think about how to group your automation in smaller, discrete chunks.

The one suggestion we’d offer is to make sure you keep a documented, principled approach to whatever you decide. There are pros and cons to different approaches, but a lack of design pattern or different approaches by different owners is sure to be chaos. Check out what Narender, Karmel, and Tom have recommended and see if that’s where you’d like to start!

• Narender Singh’s 'Multiple Flows Per Object’ design approach
• Karmel James’ 'One Flow Per Object’ design approach
• Tom Hoffman’s 'One Flow Per Object’ design approach

Resources

• Trailhead Module: Flow Builder
• Salesforce Architects Site: Record-Triggered Automation Guide

Want to see more good stuff? Subscribe to our channel!