Flow: How To Build An Efficient Flow? Understand Governor Limits
Governor limits are something that is really hard and dull (Sorry can’t help to say it!), but a REALLY important thing to learn when starting with Salesforce automation. When it comes to efficiency, some people would think it is “to build a good enough solution within the shortest time”. However, as a Salesforce admin, I don’t think good enough is enough, and the sentence above is absolutely not the definition of efficiency.
The Definition Of Efficiency
When building automation, we always have to think about this question: Whether the solution is using the least possible system capacity. In other words, whether the solution is the most efficient.
Outcomes Of Inefficient Solutions
If you skip this step, the system might still run smoothly when you have only a few flows, but you will start to see the impact when you have many records (Ex. data upload) that trigger many flows. It will take ages for the flow to finish, and if you reach the limits the whole operation will fail. The system performance might also be affected so your users need to spend more time loading pages. Thus, it is really important to review how we can build the flow in the most efficient manner.
How To Review Efficiency
There are essential two steps:
1. Check how this solution interact with other solutions
We should be aware of any duplicate or recursive triggers. Is this flow has the same triggering condition as others (Duplicate)? Will this flow trigger another flow which triggers the current flow again (Recursive)? To prevent this from happening, we need to have a good strucutre and practice in managing automation.
2. Check how much capacity this flow will cost
In layman’s terms, it can be represented by how much unit time a flow takes. By unit time, I mean we do not need to measure the actual time but only use the abstract time concept. For example, we can assume that running one action will take one unit time, then we can count how many actions there are to have an idea about how efficient the flow is. This is when the governor limits come in place and why we need to understand it. Don’t worry, I will translate everything into plain English to help you understand them easily.
The final note before we start, the goal here is not to monitor the performance like a developer, but to have the foundemetal knowledge so we as admins will have a sense on how good or bad the flow is.
The Intimidating Governor Limits
I would’ve wanted to close the tab when I see the word “governor limits”, so let me translate everything that is in this offical help article.
1. Governor Limits
Original:
Limits to ensure that any runaway flows don’t monopolize shared resources in the multitenant environment.
Translation:
Because Salesforce is on cloud, all the organizations are on Salesforce’s servers (Multitenant) and share the computing power. To prevent any specific org from using too much of that power, they have to enforce the limits for each org and each transaction. This is called the governor’s limits.
2. SOQL
Original:
Salesforce Object Query Language (SOQL) is to search your organization’s Salesforce data for specific information.
Translation:
It is a specific type of computer language that we can use to communicate with the system to retrieve a specific set of data. It is like saying “give me all accounts that I owned” but using the language that the system understands. Each request is called a query.
3. DML
Original:
Apex enables you to insert, update, delete or restore data in the database. DML (Data Manipulation Language) operations allow you to modify records one at a time or in batches.
Translation:
Like SOQL, It is a specific type of computer language to modify a specific set of data, like saying “change all my account rating into Hot”. Each request is called a statement.
4. Transaction
Original:
An Apex transaction represents a set of operations that are executed as a single unit.
Translation:
It is usually a complete run of a solution, but a flow can have several transactions or be included in a larger transaction. See below***
5. Total number of SOQL queries issued: Limit 100
Translation:
You can ask the system to retrieve specific data sets for maximum 100 times in one transaction. These are the elements that will use SOQL queries:
6. Total number of records retrieved by SOQL queries: Limit 50,000
Translation:
In each transaction, the maximum number of records you can get is 50,000. Note that it is per transaction, not per query, so the system will count all the records you have retrieved from different elements. In flow this is called “SOQL query rows”.
7. Total number of DML statements issued: Limit 150
Translation:
Similar to 5, you can ask the system to update specific data sets for maximum 150 times in one transaction. These are the elements that will use SOQL queries:
8. Total number of records processed as a result of DML statements: Limit 10,000
Translation:
Similar to 6, in each transaction, the maximum number of records you can modify is 10,000. Note that it is per transaction, not per statement, so the system will count all the records you have modified from different elements. In flow this is called “DML rows”.
9. Maximum CPU time on the Salesforce servers: Limit 10,000 milliseconds
Translation:
The actual time it takes for the Saleforce computer to execute your transaction. It depends on how complicated your solution is (whether it has too many elements or records or complex actions). We can only see this in the debug log, but I wouldn’t worry too much about this.
10. Total number of duplicate updates allowed in one batch: Limit 12
Translation:
Duplicate update means you update the “same record” in one batch, and you can only do that less than 12 times per record. As stated in this article, when you have scheduled actions, Salesforce will batch and execute them at once based on the scheduled time. To prevent this, make sure you don’t have one record having too many scheduled actions around the same time. (Although this error happens more often when using data loader)
11. Special cases for transaction
Original:
Autolaunched flows are part of the larger transaction that they were launched through and share that transaction’s limits.
Translation:
If a flow is fired from a process, another flow, or an APEX script, they will be counted as one huge transaction instead of two, and they will share the limits.
Original:
Flows with Screen/Pause elements can span multiple transactions. A new transaction begins each time the user clicks Next in a screen or the flow interview resumes.
Translation:
If you have Screen or Pause elements inside the flow, you can break the flow into several transactions.
Original:
Everything after the Pause element is executed as part of a batch transaction that includes other resumed interviews. The batch includes interviews executed by the same user ID, have the same execution time, and have the same flow version ID.
Translation:
If the paused flow interviews have the same user ID, execution time, and flow version ID, they will be executed in batch and counted as one transaction when resumed. This is because flow supports bulkification.
12. Executed elements at runtime per flow: Limit 2,000
Translation:
This is not how many elements you have put on the flow canvas, but how many times the elements are executed. For example, if you have a Loop that runs for 10 iterations, and there is one Assignment element inside the loop, you should count this Assignment 10 times instead of one.
Counting Practice
I get 20 accounts and want to create one task per account.
- Element: Get Records *1 + (Loop + Assignment) *20 + Create Records *1 = 42
- SOQL: Get Records *1 = 1
- SOQL Rows: Get Records *20 (Accounts) = 20
- DML: Create Records *1 = 1
- DML Rows: Create Records *20 (Tasks) = 20
So always try to make sure the data elements are outside the loop if possible.
How To See The Limits When Debugging
As mentioned in the debug article, when debugging autolanched flows, you can click “Show query limits in debug details”, and you will see the Element Governor Limits in the debug details. Note that this is only showing the limits used per element, not the whole transaction. If you want to see the total or want to check this for other flow types, you need to set up a trace flag in debug log.
Phewww, that concludes the horrifying topic of governor limits! I hope it is more straightforward for you now and let’s build nice, efficient flow solutions together!
Hi great article, but were points 9 and 10 meant to be the same? 9 talks about CPU time and 10 is about duplicate updates. And yet the translation text is the same.
That’s a really good catch! Sorry it must have slipped through my mind. Now I have it corrected. Thanks! 🙂
Great write up. Thank you for this Melody! At the very end of the article you mention setting up a trace flag in a debug log to the see the total count of queries. Do you have further details on how to properly set that up?
Thanks Jeff! To set up a trace flag, you can go to Setup > Debug Log. There you can create a new User Trace Flag. To see the details of flow, you would want to create a new Debug Level and set the Workflow to Finer. Once you create a trace flag and run the flow within the range of that trace flag, all the flow execution details could be found in the debug logs below. I wanted to write an article about this, but debug log is so complex so I am not able to explain every detail that easily… but hope this short summary would help:)
It would be great if you could add what constitutes one transaction in a UI flow.
Hi Shoaeb, thanks for the comment! I wrote the special cases on point 11, which includes the Screen element. If this is the detail you were looking for?
After the Winter’23 release the limit for number of executed elements per flow has been removed. Earlier it was 2000 elements per runtime flow