Automate This! — Use Formulas in Record-Triggered Flows with Aleksandra Radovanovic

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, four community Flow experts showcase a Flow feature you can use in record-triggered flows. This blog post covers the formulas feature Aleksandra Radovanovic showcased during the episode.

With every new Salesforce update, we’re gifted new, shiny Flow features that confirm its status as the most powerful declarative automation tool admins have at their disposal. One such extremely useful Flow feature is the option to use formulas.

Let’s start with defining what formulas in Flow are and how they’re different from other flow variables. Formulas are standard Flow resources and can be used as a starting condition, for setting up a field value, or as a criteria in a Decision element. However, a big difference is formulas are read-only, meaning we don’t set the value directly with them when we use them in Assignment elements. Formulas are always first calculated, and then the result of that calculation is assigned as a value to the variable. We can take advantage of that feature to build more optimized flows, as I will explain in this blog post.

Two main use cases are formulas in flow Assignment elements and formulas in the entry condition for record-triggered flows. We’ll talk about both, explain how to use them, and cover the benefits and caveats as we build flows.

Formulas in flow Assignment elements

As I mentioned, formulas in Flow are created like any variable. They have an API name. I strongly urge you to use the description field so everyone else (including yourself, after a sufficient amount of time) can understand what the formula does. This is especially true for formulas that contain complex logic. As with a regular formula field, we also need to select the formula output data type. This is especially important in flows. If you try to use a formula in a Decision element and compare text field to a formula whose output is, let’s say, a number, you’ll receive an error. The magic happens in the formula field when we have the option to not just use formula operators, but also bring in the merge fields and combine them with some additional logic. Let’s explore that in the following example.

Formula fields can help admins avoid a long-standing headache: hardcoding values in flows. In our use case, we want to track cases with Priority flag turned on and assign a different customer success manager’s email based on the Account’s Strategic relationship value. If the Strategic relationship is marked as a ‘Customer at risk’, we want to add ‘Success Lead’ to the case. In all other cases, we can assign a group email so the success managers can work through cases as they go. We can follow up on this logic by creating a variable type formula and add logic to determine which email to assign.

In order to avoid hardcoding, we’ll also use a formula to call in Custom Label with email addresses as values. If you ever tried to hard-code a record ID in your flow, you know that records have different ID value between environments. That means that if you build your flow in sandbox A and then move it to sandbox B, that flow is going to fail because IDs for the same record types are different in these sandboxes. The same would happen if you deployed that flow to production. There’s a different record ID there, too. That means that if you use hard-coded values in flows or formulas, you’ll have to have a different version in a different environment, creating a maintenance headache for everyone. In our example, we’re using Custom Label to avoid this mistake.

We can set up the initial simple and elegant decision criteria with a single condition: ‘Priority Flag equals true.’

After we have the Decision element, we can create our two variables with formulas referencing the Custom Labels.

Accessing Custom Label from the formula builder is very straightforward. Click on Insert a resource, select $Label, and from the dropdown find the one that you want to use in the formula.

This is how we create a variable whose value we’ll assign based on the Strategic relationship field value. We use an IF logical statement to check the field value; if it’s the one marking the Account that requires a specific process (as for the case of a ‘Customer at risk’), we assign it one value (Success Lead). If it’s any other value, we assign the generic email. Here’s what that formula looks like:

(IF(NOT(ISBLANK({!$Record.Account.Account_Team_Flag__c = ‘ ’})), {!lab_Exec_Sponsor_Email}, {!lab_CSM_Generic_Email})

This way, we’re simplifying the process and making the flow easier to maintain. If we ever need to update the emails of the users being assigned, we don’t have to deactivate the flow, save a new version, and replace the variables with new emails. We can simply update the Custom Label values. The flow will keep working as expected, no changes needed. Our Assignment element looks very straightforward thanks to logic we could embed within the formula field.

This same approach to logical decisions can help us avoid using a Decision element in the flow, making it simpler to understand and more performative. Here I have a flow that’s triggered whenever a case is created. It’s checking a checkbox for additional priority based on the related account’s rating. Since we can traverse related objects and use merge fields, we can assign this value using the Decision element. However, by using a formula field, we can remove the Decision element completely by moving the logic inside the formula field in the Assignment element. This is what our formula looks like:

IF(ISBLANK({$Record.Account.NamedAccount__c}), ), FALSE, TRUE)

We can have a flow like the one below where logic is nested inside the formula in a variable. In this case, we only need an Assignment element.

The flow formula can contain up to 3,900 characters, so that’s a limitation to keep in mind when building complex logic.

Formulas in record-triggered flow entry condition

As I mentioned, Summer ’22 brought us several amazing Flow features, but having formula as an entry condition was one probably most sought after. Even better news is that this new option comes with a fully built-in formula builder, the same one we’re used to seeing in formula fields on objects or in validation rules. Not only can we use a formula to define entry criteria, we can also use the insert functions and select operators. The formula builder guides us through the syntax as we build, and that simplifies the process. It also saves time and increases an admin’s productivity, as we can check syntax as we build the formula and catch errors as we create it rather than find errors upon saving the flow.

As with any other formula fields, we can also traverse through relationship fields and use merge fields. Now that we finally have that option, let’s see how we can use it.

In order to streamline the process of working on customer cases, we’ve created a flow that automatically updates the Backlog custom object. However, it should only do that for a subset of cases that belong to the community type and have the status equals ‘New’. Prior to Summer ’22, we would have to trigger the flow for every updated Case record and check the criteria by selecting the values from the dropdown. Thanks to the option to utilize a formula, we’re making the decision right at the beginning, determining if we even want to trigger that flow, and can include simple or complex logic in that decision. This is what our entry criteria for an After Save record-triggered flow looks like.

We see that it’s easy to read and can be easily enhanced if needed. And the only reminder is to build a formula in a way that the result is true or false, depending on if you want to have the flow run or not.

Things to remember

We can see that formulas in Flow are a pretty powerful addition, whether we use them in the flow entry criteria or as a variable in one of the Flow elements. As the Flow PM team continues to work on making flows even more awesome, here are the three main things to remember when using formulas in record-triggered flows:

• A formula in the entry criteria for record-triggered flows has a working formula builder, so syntax errors can be detected during build.
• Using logical expressions in formulas can simplify and streamline flows, making them more performative.
• Formulas support merge fields for more complex expressions or traversing over related records.

Resources

• Trailhead: Flow Builder
• Trailhead: Formulas and Validations