PRO TIPS

Improve Your Flows with the Transform Element

A headshot for Jay Mehta, Prolocity's PROserve Essential lead

Jay Mehta
PROserve Essentials Lead

One of the most important things for admins is staying current on newer Salesforce functionality that can make your development work more efficient or unlock new capabilities. Today, we're going to take a look at the Transform element, which Salesforce has put significant development effort into in recent releases.

Using transform can replace some older design patterns, such as looping through a record collection in order to sum up values of fields. Transform promises the following advantages:

  1. Easier to maintain and debug: using a loop means introducing more elements into the Flow, which complicates both the visual display and adds variables you'll have to sift through–debug for a transform will show only one element instead of dozens or hundreds for a loop.
  2. Better performance: Salesforce estimates that processing collections using the Transform element can be up to ten times faster than looping through
  3. Avoids execution limits: although Salesforce has relaxed Flow limits over time (for instance, the 2000 item execution limit per flow that was removed in the Spring '23 release), there are still circumstances where executing a loop over a large volume of data can cause you to bump into execution limits.

We'll illustrate the differences below. You can check out the video at the end for a full tutorial.

A Simple Example: Displaying an Opportunity Amount's Percentage of Total Pipeline

Let's say you had a requirement to display a visual alert on an Opportunity record if its value exceeds ten percent of the total open pipeline, something that looks like this:

Screenshot of a Key Deal alert, which has six key emoji surrounding the words Key Deal.

This is relatively easy to calculate in a report, but harder to display on an individual record. To do that, we'll need to determine the size of the open pipeline (i.e. the total of the Amount field on all open Opportunities). We'll then need to store that value and perform the math on open Opportunity records–for the sake of this example, we'll update each open Opportunity to set the value of the total pipeline size, and use a formula field to divide the Amount by that number.

The old way: using loops

On its face, it doesn't look so bad.

We start by getting all open Opportunities. Then, we run two loops.

The first loop determines the total amount of all open Opportunities. It does this by adding the Amount field's value of the current item to a variable inside of the loop:

Screenshot of the assignment–using an Add operator to add the current opportunity's Amount to a variable called Var_Total_Amount

Then, we'll need to run a second loop to set the field we called Total Open Value to the total amount we calculated above:

A screenshot of the assignment that sets each open Opportunity's total pipeline amount.

Finally, we'll update those records using the Update Records element. In total, that took six elements in the two loops.

Screenshot of a Flow using two Transform elements instead of loops to process all open Opportunities–it uses two-thirds as many elements.

The new way: using Transform

Now, let's look at doing the same thing with the transform element. We start by getting all open Opportunities, same as the other Flow. But now, instead of building loops, we'll use two transforms.

The first one simply calculates the total of the Amount fields of all the Opportunities we found:

Configuration of a transform mapping to sum the Amount field of a collection of Opportunities.

 

The second transform builds a text collection the IDs of each of the Opportunity records that we'll use in the Update Records element. We've cut out part of the screenshot to make it fit the screen–the mapping is from the ID field on the Open Opportunities record collection:

A screenshot showing the mapping between a text field in a collection of records (ID) into a text collection.

What's the practical result?

There are a couple of differences. Salesforce estimates that in some operations, a Transform element may perform operations ten times faster than loops. In our testing of this simple Flow, it consistently ran at least 25% faster.

Another difference is in debugging. When debugging the first Flow, the debugger shows a step for every iteration of the loop. If your loop processes hundreds or thousands of records, this can make debugging difficult. If you've ever gotten a Flow failure email that Outlook couldn't reliably open, you know this pain.

The debug for the Transform element is quite a bit tidier:

Flow debug output for the flow showing four elements–the get records, two transforms, and record update elements.

Clicking one of the transforms shows a preview of the records that it processed, along with the output:

Clicking a transform element shows the records that the element processed in JSON format, along with the actual output (in this case, a total of $4.3m in total amount).

This is just a basic example–there are many other things we could do with the Transform element. It has the ability to convert records quickly into other types (like converting Leads into Contacts to insert). It can also combine data from external systems into a single type of records to insert (for example, orders from multiple external systems).

For more details on how we built this flow, view the tutorial below: