Limit-Consuming Elements Inside Loops

What are limit-consuming elements and why are they bad in loops?

Certain elements count towards one or more Salesforce governor limits. If these elements exist within a loop, those limits can quickly be reached, which makes the flow likely to fail due to exceeding governor limits. In the context of record-triggered automation, this causes not just the flow to fail, but the whole transaction to be rolled back.

The limit-consumption types evaluated by the flow analyzer are:

• SOQL queries
• DML
• Single email deliveries that count towards general email limits

SOQL Queries

There is a per-transaction limit of 100 queries in a single transaction, which is why it is so important to avoid executing it in a loop with an unknown size. Queries come in a couple flavors in Salesforce flows; the first of which is obviously a Get Records element, but the second being an Update Records or Delete Records element that uses filter criteria instead of record elements.

To admit, this one was hard to avoid without the involvement of Apex until the Winter '23 release where Salesforce introduced the In and Not In operators. Now, instead of querying inside a loop, you can build a list of text elements and use these operators in a query after the loop. This is demonstrated by the below example where we have a list of contacts and need to get the list of opportunities related to the same accounts as the contacts.

DO NOT DO THIS

INSTEAD DO THIS

DML

DML stands for data manipulation language, and refers to any action that is making a change to the Salesforce database. In the context of flows, this includes Create Records, Update Records, and Delete Records elements. Executing DML inside of a loop can easily be avoided by compiling a list of records within the loop and executing the DML statement after the loop. Please see the below example.

DO NOT DO THIS

INSTEAD DO THIS

Single email deliveries that count towards general email limits

This limit flies under the radar for a lot of organizations, but can be very unexpected and very restrictive at scale. How restrictive?

Each licensed Salesforce org can send single emails to a maximum of 5,000 external email addresses per day based on Greenwich Mean Time (GMT).

That limit is a hard limit regardless of how many users your org has, what edition you are on, you will never be able to exceed that limit. Now, this may never be a problem for your organization because you may never send emails at this scale, but if you are sending transactional emails using Salesforce, this limit can easily be hit. For that reason, the flow analyzer will point out when you are using a single email action that will count towards this limit. The next question may be, when would a send email action count towards the general email limits? According to the documentation,

If you’re using Log Email on Send or Email Template ID, the daily email send limit is based on the single email limit.

That is exactly what the flow analyzer is looking at and will let you know if you have this occurring inside of a loop.

When it comes to avoiding this, the best option is typically to use an email alert instead. The limits are much more lax for email alerts and will scale with the number of users in your org.