Bulkification and Governor Limits in Flows

Why This Topic Matters

Salesforce runs on a multi-tenant architecture, meaning thousands of organizations share the same infrastructure. To keep one org from monopolizing resources, Salesforce enforces governor limits — hard caps on things like the number of database queries, DML statements, and CPU time a single transaction can consume. Flows, as the primary declarative automation tool, are subject to these limits just as Apex code is. For an Advanced Administrator, understanding bulkification and governor limits is critical because poorly designed flows are the single most common cause of production failures when records are updated in bulk via Data Loader, integrations, or mass actions. The exam tests whether you can design flows that are efficient, scalable, and resilient under real-world data volumes, not just for a single record in a demo.

What Governor Limits Are

Governor limits are per-transaction thresholds enforced at runtime. The most relevant ones for flows include:

• SOQL queries: 100 per synchronous transaction (200 for asynchronous). Each Get Records element consumes one query.
• DML statements: 150 per transaction. Each Create, Update, or Delete Records element (when executed) consumes one DML statement.
• Records retrieved by SOQL: 50,000 per transaction.
• Records processed by DML: 10,000 per transaction.
• CPU time: 10,000 milliseconds synchronous, 60,000 asynchronous.
• Executed elements at runtime: Flow has its own limit of 2,000 executed elements per flow interview (this was historically a hard limit; Salesforce has relaxed it in newer releases, but the exam may still reference it as a design concern).
• Email invocations: 10 per transaction.
• Heap size: 6 MB synchronous, 12 MB asynchronous.

When any limit is exceeded, the entire transaction fails and rolls back. In a record-triggered flow, this means the user or integration receives an error and no records are saved.

What Bulkification Is

Bulkification is the practice of designing automation so that it processes many records together in a single operation rather than one record at a time. Instead of performing one DML statement per record (which would hit the 150 limit quickly), a bulkified process collects records into a collection and performs a single DML operation on the whole set.

Salesforce automatically bulkifies record-triggered flows and flows launched in bulk contexts. When 200 Accounts are updated via Data Loader, Salesforce does not run 200 separate flow interviews in isolation. Instead, it runs 200 interviews in parallel and, when they reach the same Get Records or DML element, it combines those operations into a single SOQL query or a single DML statement. This is why a correctly designed record-triggered flow can handle a batch of 200 records with only one query and one DML, even though the flow logic appears to run per record.

How Bulkification Works in Practice

Automatic bulkification applies to:
• Record-triggered flows (before-save and after-save)
• Flows launched from Process Builder or Apex in bulk
• Scheduled flows (which run in batches)

Automatic bulkification does not rescue you from poor design inside the flow. The key danger is DML or Get Records inside a loop. If you place a Create Records or Update Records element inside a Loop element, the flow issues one DML statement per iteration. With 200 trigger records, each looping over 5 related records, you could issue 1,000 DML statements and blow past the 150 limit immediately. Bulkification across interviews cannot merge operations that occur in different loop iterations within the same interview.

The correct pattern is:
1. Use a Get Records element before the loop to retrieve all needed records at once.
2. Loop through the collection and make changes to each record variable in memory using Assignment elements.
3. Add each modified record to a new collection variable using an Assignment element.
4. After the loop ends, use a single Update Records (or Create Records) element on the collection.

This yields one query and one DML regardless of how many records are in the loop.

Before-Save vs After-Save Flows

Before-save (fast field update) record-triggered flows are the most efficient option for updating the triggering record. They do not consume a DML statement because the change is made to the record in memory before it is written. They are roughly ten times faster than after-save flows and should always be the first choice when you only need to update fields on the same record. After-save flows are needed when you must create or update related records, send emails, call actions, or run asynchronous paths.

Asynchronous Paths and Scheduled Paths

After-save record-triggered flows can include an Run Asynchronously path, which executes in a separate transaction with its own governor limits. This is a powerful tool for offloading heavy work (such as external callouts or large updates) so it does not count against the original transaction's limits. Scheduled paths similarly run in separate transactions at a later time. Scheduled flows run in batches of 200 records and have a daily limit of 250,000 scheduled flow interviews (or the number of user licenses multiplied by 200, whichever is greater).

Screen Flows and Transactions

In screen flows, a new transaction begins each time a screen is displayed, each time a Pause element is reached, and after certain actions. This means governor limits reset at each screen, which is useful but also means you cannot rely on a rollback across screens. Fault paths help handle errors gracefully.

Entry Conditions and Efficiency

Use entry conditions on record-triggered flows (and the option to run only when a record is updated to meet the conditions) so the flow does not launch unnecessarily. Fewer interviews means fewer resources consumed and less chance of hitting limits. Also, limit the number of record-triggered flows per object and use Flow Trigger Explorer and trigger order to manage execution sequence.

Debugging and Monitoring

Flow debug logs and the Debug feature in Flow Builder show governor limit consumption. The Automation App and Flow Error emails report when limits are exceeded. Use the "Rollback records" element in screen flows to undo changes within the current transaction when an error occurs. Fault connectors should be added to DML elements to catch failures and provide meaningful messages.

Exam Tips: Answering Questions on Bulkification and Governor Limits in Flows

1. Spot the loop trap. If a scenario describes a flow that fails when records are loaded via Data Loader but works for a single record, the answer almost always involves a Get Records or DML element placed inside a loop. The fix is to move the DML outside the loop and use a collection variable.

2. Prefer before-save for same-record updates. If the question asks for the most efficient or best-performing way to update fields on the triggering record, choose a before-save (fast field update) record-triggered flow. It uses no DML and avoids recursion.

3. Know the key numbers. Memorize 100 SOQL queries, 150 DML statements, 50,000 records retrieved, 10,000 records in DML, and 10 email sends per transaction. Questions may give you a scenario with specific counts and ask whether it will succeed.

4. Automatic bulkification is real but limited. If an answer claims that flows are not bulkified and therefore Apex is required, be skeptical. Salesforce bulkifies record-triggered flows automatically. However, if the answer claims bulkification will fix DML inside a loop, that is wrong.

5. Asynchronous paths reset limits. When a scenario involves callouts, heavy processing, or hitting limits in an after-save flow, consider the Run Asynchronously path as the solution rather than rewriting everything in Apex.

6. Scheduled flows batch at 200. Know that scheduled flows process records in batches and that the daily interview limit applies.

7. Screen boundaries reset the transaction. If a screen flow question mentions a limit being exceeded, remember that each screen starts a new transaction; restructuring the flow with additional screens or a Pause element can be a valid answer.

8. Use entry conditions and decision elements early. Answers that reduce the number of records entering the flow or that filter before performing operations are generally correct choices for efficiency.

9. Rule out Process Builder and Workflow Rules. These tools are retired for new automation. If an option recommends them for scalability, eliminate it.

10. Read for keywords. Terms like "scalable," "large data volume," "mass update," "integration," and "performance" signal that the question is about bulkification and limits. Choose the answer that minimizes queries and DML and keeps operations outside loops.

By mastering these principles, you will be able to design flows that survive real-world data loads and confidently answer exam questions that test whether you understand how Salesforce's shared infrastructure constrains declarative automation.