Automate This! — Discover Tips and Best Practices for Record-Triggered Flows

The Flow Code

Did you know there’s a super-secret group of Flow fanatics (aka Flownatics) who work behind the scenes of society to add flows into every aspect of daily life? Well, there isn’t. Brian Kwong and I totally made that up because we just like any excuse to put on shadowy robes and act like we have something important to say.

But if you build flows for your Salesforce org, we do have important things to say! That’s why we’ve assembled The Flow Code, a three-ring binder containing all the wisdom of the ages... at least when it comes to flows. Today, we’re sharing some of the choicer bits, specifically about record-triggered flows. Here they are, in no particular order.

Code 145: Know Thy Limits

Flow is certainly powerful, but it’s part of a larger system. So, rather than let it run wild and suck up all the servers’ CPU, we have to place limits on it. There are broad, overarching things that can affect any aspect of your flows, such as CPU time limits and number of query limits, but there are also limits that only affect specific things. For example, did you know that you can’t convert leads that are referenced in a Pause element? We didn’t!

These limits sometimes change with major releases, but rather than us list all of them here, your best bet is to read through the Flow Limits and Considerations on Salesforce Help. By learning more about the limits of Flow, your flows will break less often and you’ll have a better idea of what could be going wrong when you troubleshoot.

We might even be getting a major limit removed in the Spring ’23 Release (Safe Harbor!), so keep your eyes peeled on those release notes, too!

Code 1138: Have NOT Too Much Time on Your Scheduled Paths

Scheduled paths allow your record-triggered flows to do things at a later date or time. This is very useful, but what do you think happens to your flows when they’re asked to wait? Think of flows with scheduled paths like a visit to the DMV. You don’t take a number then just melt out of existence only to appear once again when needed. You sit, probably not doing anything except patiently waiting for your time to come.

But just like waiting at the DMV, if something goes wrong, the whole wait can be thrown out. The longer those flows have to wait, the more likely something can go wrong. You can make scheduled paths that even wait for months, but be aware that those flows have an increased chance of failure. Look out for the following scenarios.

• If the user that triggered the flow is deactivated, when the flow resumes, the flow will fail.
• There’s a limit on the number of waiting flow interviews. If a flow runs and this limit is exceeded, the flow will fail.
• Remember what we said earlier about not being able to convert leads when the lead is involved in a Pause element? This applies to scheduled paths, too!

Code 3: Always Build and Test in a Sandbox

Notice how this code has a really low number? That’s because it’s SUPER IMPORTANT.

When you’re ready to start putting together a new flow, ALWAYS build it in a sandbox and not in production. No excuses! Ever! Never ever!

Why? Because automation is, well, automatic. You might think you know what you built, you might believe it’s going to do exactly what you want it to do. But it might not. And production is your org’s precious data, which is not easy to fix if your untested flow goes rogue and starts changing all your contacts’ names to “Matthew McConaughey” because that was your sample text and you thought it was funny because he’s done all these Salesforce commercials lately, and you’re pretty sure you removed that sample text but actually you didn’t and now it’s run IN PRODUCTION and you have to explain to your boss’s boss’s boss why the whole Sales team needs to review their contacts after you hastily try to reconstruct the names from related records. Not that this happened to us or anything...

So, the next time you think, “Oh, I can just do this real quick in production, it’s so simple, what could possibly go wrong?” Just don’t. Trust us. Build your flow in a sandbox first, and test it thoroughly so you know exactly what it’s going to do.

Code 3b: Test as Other Users Lest Ye Be Judged

While we’re on the subject of testing, this corollary of Code 3 is important to note as well. The only way to be absolutely sure that your users can run your flows as expected is to log in as them. You might think just simulating their profile is enough, but sometimes flows hit other roadblocks like field-level security, permission sets, and role-based sharing. These things can all create scenarios where users don’t have access to the records or fields that you think they do.

Don’t worry—to test as another user, you don’t need their password. Flows have a feature that make it easy, but you have to enable it.

In Setup, on the Process Automation Settings page, there’s a setting called ‘Let admins debug flows as other users’. Turn this on by checking the box, and click Save. You’ve now enabled the feature to run a flow as another user in the Debug window.

Now when you click Debug, you have the option to select the user that “runs” the flow for that debug run. Check the box for Run flow as another user, and select the user’s name in the lookup field. When you run the debug, you see what they would see and get details about any errors they would receive.

Code 37: You + Release Notes = Profit

This might seem obvious, because so much of Salesforce revolves around the release notes. However, this is especially important for Flownatics! There’s a massive amount of work being done for Flow every release, so it’s easier than ever to get lost when the wave of changes hits. We know release notes are massive, but if you build flows, make sure you prioritize reading that section of the release notes every release.

Code 9001: A Wise Admin Neglects Not the Flow Trigger Explorer

If you’ve been working with Salesforce automation, you may have heard recommendations in the height of the Process Builder era, suggesting that it’s best to have one process or flow per object. This was suggested so you could easily track your automation and control the order that automated actions were executed. Well, no longer! The Flow Trigger Explorer allows you to see all the flows that trigger for a specific object and record action, and control the order in which they execute. Also, it turns out that having a single flow that runs on every record create or update isn’t great for performance. ?

You can navigate to the Flow Trigger Explorer by clicking the Flow Trigger Explorer button on the Flows page.

And here’s something cool you can do from the Flow Trigger Explorer. If you click New Flow here, Salesforce auto-fills the flow settings based on where you clicked. So if ‘When a Lead record is Created’ is selected and you click New Flow in the Fast Field Updates bar, a new record-triggered flow opens, with Lead, Created, and Fast Field Updates already selected for you!

Code Three Hundred Billion Gazillion: Entry Criteria Are Their Own Reward

When creating a record-triggered flow, keep in mind that by default that flow will run every time a record on the selected object is created, updated, created or updated, or deleted. When the number of record-triggered flows starts adding up in your org, this can massively slow things down and increase the chances of unexpected interactions between multiple flows.

Instead, you can set entry conditions in the flow’s Start element. If the affected record doesn’t meet those conditions, the flow doesn’t even run! No increased load times and no unexpected interactions!

Code 867: Seek the Path of Fast Field Updates

Speaking of load times, you’ve probably noticed the Fast Field Updates option in the Start element for record-triggered flows.

You should always select this option if your flow supports it. Fast Field Update flows are faster, have reduced likelihood of hitting database limits, and run before the triggering update is saved to the record.

So, how do you know if your flow supports Fast Field Updates? You can select this option on any record-triggered flow that follows these rules:

• The flow’s Update Records elements update only the record that triggered the flow.
• The flow doesn’t contain any Create Records, Action, Delete Records, or Subflow elements. You can remember this list of elements by thinking of the first letter of each element—they spell CADS!

If your record-triggered flow meets both of these criteria, you should set it to Fast Field Updates!

Code 5309: On the Path of Fast Field Updates, Never Update When You Can Assign

While we’re talking about Fast Field Updates, did you know that you can update a record without using an Update Records element?

In a Fast Field Update flow, you can use an Assignment element to assign values to fields in the $Record variable. The $Record variable is the triggering record, and remember, the Fast Field Updates setting makes your flow run before the triggering change is made in Salesforce. By changing fields directly in $Record, those new values hitch a ride with the triggering change and get changed, too. This makes the flow run even faster and reduces server load even more!

Code 223: A Flownatic’s Flows Never Have Hard-Coded IDs

What is a hard-coded ID? Every Salesforce record has a unique 15- or 18-character ID (it can be shown either way depending on where you see it). Theoretically, it’s possible to copy-paste that ID directly into a flow; you might want to use it when specifying one particular record or when setting a specific record type.

But you should NEVER, EEEEEEEVER use hard-coded IDs in a flow! Or in any piece of automation! Ever!

Salesforce can change a record’s ID at any time and has had to change them in the past. Plus, if you’re building in a sandbox—like you should—that record ID might not be the same ID in production. Not to mention that it’s super hard to troubleshoot flows if you’re just seeing an ID instead of a recognizable value.

If you need an ID in a flow, use a Get Records to retrieve it instead. You can even get record type IDs by running a Get Records on the Record Type object!

You’re now a Flownatic!

Now that you’ve learned more about building flows, congratulations—you’re officially a Flownatic! May you forever hold flows as the primary starting element deep in your heart, mind, soul, and web browser. May you never underestimate the power of the flow and forever remain flowficient. May the flows be with you, always!

Resources

• Trailhead: Flow Builder
• Trailhead: Record-Triggered Flows
• Salesforce Help: Flow Limits and Considerations

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