| View supported editions. |
| User Permissions Needed | |
|---|---|
| To open, edit, create, activate, or deactivate a flow using all flow types, elements, and features available in Flow Builder, including Einstein and Agentforce for Flow: | Manage Flow |
| To view Setup and access debug logs: | View Setup and Configuration |
| To view, retain, and delete debug logs, and set trace flags: | View All Data |
| Problem | Solution | Prevention Technique |
|---|---|---|
|
Data Manipulation Language (DML) Operations Inside Loops Performing Create Records, Update Records, or Delete Records operations inside a loop path consumes CPU time with each iteration. Processing multiple records one at a time can quickly exhaust the limit. Example: A flow loops through 100 opportunities and uses a Create Records element inside the loop to create a task for each opportunity, resulting in 100 separate DML operations. |
Use Collection-Based Data Manipulation Language (DML) Operations Inside the loop, use Assignment elements to add records to a record collection variable. After the loop completes, use a single Create Records, Update Records, or Delete Records element to process the entire collection at once. This approach is called bulkification. Example: Loop through opportunities, use an assignment element to build a task for each opportunity. Then use another assignment element to add each task to a collection variable. After the loop, use a Create Records element to create all tasks at once. For more information, see Flow Bulkification in Transactions. |
Never place DML operations inside loops. Always design flows to collect records in a collection variable during the loop, then perform DML after the loop completes. |
|
Multiple Queries Inside Loops Get Records elements inside a loop consume significant CPU time, especially when querying large objects or using complex filters. Example: A flow loops through accounts and uses Get Records inside the loop to get related contacts for each account, resulting in one query per account. |
Query Data Before Loops Before the loop, use a single Get Records element and use the get related records functionality to get all necessary data with appropriate filters. During the loop, use the collected data rather than querying on each iteration. If you can't use a single Get Records element, use a Get Records element to get the primary records. Then, use another Get Records element to get the secondary records. Filter the secondary records using a record field, the In operator, and the first Get Records collection. For example, Account ID > In > Accounts from Get Accounts. Example: First get all related contacts with a Get Records element that filters by the account IDs, then reference the contacts collection during the loop. |
Avoid queries inside loops. Get all necessary data before entering the loop. |
|
Complex Formulas in Loops Assignment elements that run complex formula calculations on each loop iteration accumulate CPU time, particularly with string manipulation, date calculations, or nested functions. Example: A flow loops through 500 records, and each iteration performs multiple formula calculations to derive field values. |
Simplify Formulas Break complex formulas into simpler steps. Calculate values that don't change outside the loop. Avoid nested functions when possible. Consider using formula fields on the object instead of flow formulas. For operations on entire collections—such as filtering, mapping, or sorting—a Transform element performs more efficiently than a loop. To get all related records in a single query instead of one query per loop iteration, use a Get Records element with the IN operator. For more information, see Transform Element. |
Simplify formulas and move calculations that don't change outside the loop. Test formula performance with realistic data volumes. |
|
Processing Large Record Collections Scheduled flows or batch operations that process thousands of records in a single transaction, even with proper bulkification, can consume too much CPU time. Example: A scheduled flow gets 5000 account records and performs complex transformations on each record's data before updating them. |
Use Alternative Approaches For large data volumes, consider:
|
Filter data early to reduce the number of records processed. Use Get Records filters to get only the records you need. Test with realistic data volumes before deploying to production. |
|
Multiple Flows in a Transaction When one flow triggers other flows (through record changes or subflows), the cumulative CPU time of all flows in the transaction counts toward the limit. Example: A record-triggered flow on Account updates runs multiple subflows and also triggers other record-triggered flows on related objects. |
Reduce Flow Chains Consolidate related automation into fewer flows. Review your flow trigger criteria to ensure flows run only when necessary. Consider using entry conditions to limit when record-triggered flows run. |
Review the cumulative impact of all automation (flows, processes, workflows, triggers) that can run in the same transaction. Monitor and optimize the entire automation chain. |
|
Bulk Data Loads Record-triggered flows that run during bulk data imports or mass updates require efficient processing of all records. Inefficient flows hit CPU limits during bulk operations even if they work fine for individual records. Example: A user imports 200 account records. The before-save record-triggered flow performs multiple lookups and calculations for each account. |
Optimize for Bulk Operations
For more information, see Transform Element. |
Always assume record-triggered flows process multiple records simultaneously. Test with bulk data loads (by using Data Loader or mass updates) before deploying to production. If not properly designed, a flow that works perfectly for individual records can fail during bulk operations if not properly designed. |