Part 1: Move smoothly with these Record-Triggered Flow tips

Salesforce Flow is a visual tool that allows you to build automation using elements, connectors, and resources on a canvas with a drag-and-drop interface. In their Flow Basics Trailhead module, Salesforce describes it as “an automation configuration saved in Salesforce with the structure of a flowchart.” Flows can run in different contexts: Some are run through user interaction, and some are run in an automated fashion.

Record-triggered flows are a subcategory that runs whenever a record on an Object (such as an opportunity record) is created, updated, or deleted. These trigger contexts are critical to the flow (e.g. when a case record is created, set the status to new if owned by a queue or in progress when owned by an individual).

These tips are not dogmatic principles and should be taken with the understanding that each team and Salesforce org’s needs are different. Ultimately what works best for your team will prevail, but hopefully these tips provide some perspective on ways to approach a complex and subjective topic.

It’s OK to have more than one flow per Object

Control the order of execution visually with Flow Trigger Explorer

Historically, Salesforce automation architecture relied heavily on the concept that Apex Triggers and Process Builders (soon to be obsolete) should have “One Trigger/Process per Object” to simplify and guarantee order of execution.

The Flow Trigger Explorer also allows you to easily see which Flows are active or inactive. You can jump into any Flow on one object directly from the Explorer for any edits needed in a test environment.

With these benefits, Flow Trigger Explorer relieves a developer from maintaining the order of execution and criteria for execution in Apex .

Add helpful context in Flow names

Practice good naming conventions with your Flows. As much as it’s helpful to see all the flows that run when a record is saved on an Object, it creates confusion when a Flow’s name isn’t clear or is broader than the functionality it is providing. An example of a good name mentions the intent of the Flow, as well as the affected records or fields of the Flow. Opt for longer names which are more descriptive (i.e., less acronyms) to provide clarity to what the Flow does. If the Flow’s functionality grows over time, it’s fine to update the Flow name to represent the Flow’s updated purpose. For example, instead of calling a flow “Account Updates” or “APAC Marketing Context,” think about actionable names like “Set Accounts in APAC Region to latest APAC Marketing Campaign.” The less that someone else (or you in the future) has to click into a Flow to see what it’s doing, the better!

Don’t run a Flow if it doesn’t need to run—use entry conditions

Some of the hardest bugs to debug are ones which occur when many things are running at once. Take this scenario: In your User Interface tests, you notice your Account record’s field is being incorrectly updated on save. But when debugging your Flow in isolation, the field update runs fine, and everything looks right. However, you ultimately find a different Flow that’s updating the field! A work around to that? Using entry conditions.

With Entry Conditions, a Flow will not run if the record does not meet its entry criteria. Having good, mutually exclusive entry conditions avoids conflicts while also improving performance.

Try to plan entry conditions around fewer, broader fields—as opposed to many fields that often are in sync with each other. For example, the Opportunity StageName represents the Opportunity lifecycle, and Flows are typically tied to these Stages.

If your Opportunity record isn’t considered in a “Presenting” stage until some set of fields (amount fields, address fields, contact information, etc.) is populated, then you don’t add all the fields as Entry Conditions to your flow when the Opportunity Stage field equaling “Presenting” suffices. Just use the Opportunity StageName field for that Entry Condition!

Statuses, type fields, and thresholds on number field values are examples of good entry conditions; it should not be difficult to identify which records would meet the criteria and which do not. Plan to have test records that offer a good sample of possibilities—and include records in the testing sample that don’t meet the criteria, too. 

Consider Apex actions in a Flow before turning to Apex Triggers

While it’s true that Apex Triggers do all that Flows can do (and more), the barrier to entry on writing an Apex Trigger is much higher than creating a Flow. This is an acceptable trade-off for some teams, but for others it can create bottlenecks for maintenance and enhancements only workable by a smaller team.

Flow isn’t a one-size-fits-all solution and Apex remains a very powerful tool that will still be required for complex processes. Compartmentalize (and minimize) the need for Apex and let Flow do what it does best: being a visual flowchart for the business logic. Use Apex to supplement that flowchart when needed.

With this approach, Apex Actions are functions that only do one thing in your Flow. They should be treated as black boxes from the Flow’s perspective and be tested using Inputs that produce predictable outputs for the Flows that use them.

This concept is key. It allows the Flow designer to assume and (more importantly) trust what an Apex Action does so they feel comfortable using it in Flows.

An Example in Practice

A custom Account Team object is utilized to assign a team of users to an Account, currently a manual process. For most regions, the assignment is straightforward and there’s only select teams per region. But for one region, the assignment is based on complex evaluation like looking at the zip code, account industry, and company size to find applicable team members before assigning the account to a team.

In this scenario, a good compromise would be to keep the simple assignments and overall filtering of records in the Flow but then call to an Apex Action for the complex portion.

With this breakdown, additional regions can be easily added to the decision element (diamond shape), and developers only need to worry about and test the assignment logic for the U.S. We have avoided writing an Apex Trigger for simple assignments and overall record filtering.

Conclusion

Apex and Flows are not an either-or decision. They can co-exist together and be used in “trigger-like” contexts thanks to Flow Trigger Explorer, Record-Triggered Flow Entry Criteria, and Apex Actions.

When carefully considering the topics above, you can add Record-Triggered Flows to your automation tool arsenal cleanly and quickly. In the next part of the series, we’ll look at subflows, and how they can help you share functionality between flows that run behind the scenes and flows that run on your screen!

Authored by: Nate Helterbrand