Salesforce Flow loops are a powerful tool to perform operations on collections of records. But they can be a little confusing to understand. That confusion can lead to some bad potential outcomes, creating problems in your org.
Using Flow Loops
Today, we’ll discuss how Salesforce flow loops work, and a common mistake to avoid. In essence, a flow loop is a way to take a collection (like a list of records), break each one out, and perform actions on each record individually. After the entire list is complete, your flow can proceed to the next path.
Some common use cases for flow loops come when dealing with records on related objects. For example, looking at each individual opportunity line item related to an opportunity. Or if you needed to find all contacts associated with an account.
In recent releases, Salesforce has greatly simplified the process of using loops. If you choose to use the new Auto-Layout feature, it makes the layout logical and easy to follow. In either layout view, Flow automatically creates collection variables, so those no longer have to be created separately.
The Flow Orchard
The analogy I like to use to explain the process is this:
You head to an orchard to pick some apples. In preparation, you bring a basket to hold all of the apples you pick for the day. You pick the 20 apples you want and place each one in the basket.
In this scenario, the orchard is the Salesforce database. Each apple represents a Salesforce record, and the basket is a collection variable. You gather the records you want and bring them back together.
After you bring back all of your apples, you need to wash them. You proceed to take each apple out of the basket, wash it, then place it into the bowl.
Here, taking each apple out of the basket is the flow loop. You handle each record individually to perform an action (washing). Then the modified records go into a new collection variable, represented by the bowl.
After you finish washing all of the apples, you take the bowl of clean apples back to your car. Now you’re ready to bake a pie!
Once the loop is complete, you can take the new collection of records (bowl) and perform a new action on the entire group. In this case, you take the entire collection on to the final step.
Avoiding DML Issues
Since Salesforce is a multi-tenant environment, there are specific areas that they limit in order to protect shared resources. An important limit to consider is the number of times you can hit their database in a transaction. That limit applies to code, as well as automations like a flow.
If you go back and forth too often in a transaction, your flow will fail. A very common cause of this is when a database level transaction (known as a DML operation) happens inside of Salesforce flow loops.
Imagine we went back to our previous example. You went back to the orchard. This time, instead of gathering all of the apples in a basket, you grabbed each one by hand. After picking a single apple, you walk back to the table, wash that single apple, then take it to your car.
For each apple, you perform the same process. Each one handled from start to finish. In the end, you would end up with the same result, 20 washed apples in your car. But you can imagine how inefficient that would be. It would take you much longer, and represents a lot of wasted effort.
This is exactly what happens when you place database level interactions within a flow loop. You are asking the flow to go back and forth to the Salesforce database for every record in the collection.
In a flow, there are 4 types of database interactions: Create Records, Get Records, Update Records, and Delete Records.
If you have a collection of many records, and you perform an update to each one within the loop, you’re at risk of hitting DML limits. If you’ve ever received this message:
Error Occurred During Flow: Too many DML statements: 151
you may have a flow that isn’t bulkified. This term is applied to code and automations that are set up to handle large volumes of records. The most common issue for non-bulkified automations is DML within a loop.
Bulkify Your Flow
So, how do you solve the issue? The process is simple, move your DML (Get, Create, Update, and Delete) operations to outside of your flow loop.
This image shows the right and wrong place to place those interactions. Think of the orchard analogy and make sure you leverage baskets and bowls (collection variables) to simplify your work.
Using the flow image above, let’s imagine we’re looking to update several fields on each account we have returned from our Get step. If we update each account individually, our flow isn’t bulkified. Instead, we would use an Assignment step inside the loop. Using that assignment step, we can update fields on each record, without sending that to the database.
This allows us to make our updates without DML statements. After we’ve made changes to each record in the collection, we can update all records from the collection variable at once. This gives us a single DML transaction, with multiple records updated at the same time.
I hope this clarifies bulkification of flows, and how to effectively use flow loops and assignments.
Do you have any flow tips? Leave any tips or questions in the comments below!