6.4 Flow Execution Architecture, Bulkification & Fault Paths

Flow Execution Architecture, Bulkification & Fault Paths

Salesforce Flow operates on the exact same underlying multitenant database engine and execution runtime as Apex code. Consequently, flows are governed by the exact same Governor Limits that constrain programmatic development. When an automation violates a governor limit, the platform immediately aborts the transaction and rolls back all database modifications executed during that request.

For a Salesforce Platform App Builder, architecting flows that are fully bulkified, resilient against unexpected data exceptions, and thoroughly tested is essential for enterprise-grade deployments.

---

Multitenant Governor Limits & Platform Bulkification

Every automated transaction in Salesforce operates under strict runtime boundaries:

• Total SOQL Queries Issued: 100 in the documented Flow transaction budget.
• Total DML Statements Issued: 150 per transaction.
• Total Records Retrieved by Queries: 50,000 records.
• Total Records Processed by DML: 10,000 records.
• Maximum CPU Time on Servers: 10,000 ms (10 seconds) in the documented Flow transaction budget.

Platform Automatic Bulkification

When a bulk operation occurs—such as a user importing 200 records via Data Loader, a third-party REST integration pushing a batch of contacts, or an Apex trigger updating multiple records—Salesforce groups records into batches of up to 200 records.

For Record-Triggered Flows, Salesforce creates a separate flow interview for each record in the batch. However, the platform automatically bulkifies data operations across interviews: if 200 flow interviews reach an identical Get Records element, Salesforce combines them into a single optimized SOQL query. Similarly, when interviews reach an identical Create Records element, Salesforce executes a single bulk DML insert statement.

---

The Golden Rule of Flow Design: No DML or SOQL Inside Loops

Inside an individual flow interview, the most catastrophic architectural anti-pattern is placing a Data element (Get Records, Create Records, Update Records, Delete Records) inside a Loop element.

  ANTI-PATTERN: DML / SOQL INSIDE A LOOP (GOVERNOR LIMIT FAILURE)
  ┌──────────────────────────────────────────────────────────────┐
  │ Loop (Iterates 151 Times)                                    │
  │   └──► Update Records (DML Statement per iteration!)        │
  │          └──► CRASH: System.LimitException: Too many DML: 151 │
  └──────────────────────────────────────────────────────────────┘

  ENTERPRISE PATTERN: COLLECTION ASSIGNMENT (1 DML STATEMENT)
  ┌──────────────────────────────────────────────────────────────┐
  │ Loop (Iterates 151 Times)                                    │
  │   ├──► Assignment 1: Update field values on current item     │
  │   └──► Assignment 2: Add item to Target Collection Variable │
  │ Loop Exits (After Last Item)                                 │
  │   └──► Update Records (Single DML Statement on Collection!)   │
  └──────────────────────────────────────────────────────────────┘

Why Loops Multiply Limits

When a loop processes a collection of records, every element inside the loop executes once per item:

• If a loop iterates over 101 records and contains a Get Records element, the flow executes 101 distinct SOQL queries, triggering a fatal System.LimitException: Too many SOQL queries: 101 error.
• If a loop iterates over 151 records and contains an Update Records or Create Records element, the flow executes 151 separate DML statements, crashing the transaction with System.LimitException: Too many DML statements: 151.

---

The Enterprise Collection Loop Pattern

To safely process record collections without violating governor limits, app builders must master the Enterprise Collection Loop Pattern. This pattern relies on in-memory Assignment elements to stage changes and issues a single bulk DML statement outside the loop:

Step-by-Step Architecture

1. Query Outside Loop (Get Records): Query the required records once before entering the loop. This consumes exactly 1 SOQL query and stores the results in a Record Collection Variable (colSourceRecords).
2. Initialize Target Collection Variable: Create an empty Record Collection Variable in the Manager tab (e.g., colRecordsToUpdate).
3. Loop Over Collection (Loop): Configure the Loop element to iterate through colSourceRecords. For each iteration, Flow Builder automatically creates a loop item variable representing the current record (currentItem_LoopName).
4. Modify Record Attributes (Assignment Element 1): Use an Assignment element to modify field values on the loop item variable. For example: {!currentItem_LoopName.Status} Equals 'Closed'.
5. Stage to Target Collection (Assignment Element 2): Use a second Assignment element (or add an assignment line) to append the modified loop item variable to your target collection variable using the Add operator: {!colRecordsToUpdate} Add {!currentItem_LoopName}.
6. Execute Bulk DML Outside Loop (Update Records): Connect the loop's "After Last Item" path to a single Update Records element. Configure the element to update the entire colRecordsToUpdate collection.

By following this architecture, the flow issues one Get and one collection Update instead of one per item. Those operations can invoke other automation, which shares the transaction budget; row-count and CPU limits still apply.

---

Fault Paths & Exception Handling

Even a well-architected flow can encounter unexpected runtime exceptions: a record may fail a validation rule, a required field might be null, an external ID might be duplicated, or record lock contention may occur.

By default, when an unhandled exception occurs in a flow:

• The entire transaction fails and rolls back all database changes.
• The interacting user sees a generic, unhelpful error message: "An unhandled fault has occurred in this flow."
• An automated technical fault email containing the stack trace is sent to the author or configured Apex exception email recipients.

Implementing Fault Connectors

In Flow Builder, every Data element (Get, Create, Update, Delete) and Action element supports a Fault Connector (represented by a red dashed line). When an exception occurs at that element, execution immediately diverts to the fault path rather than crashing the transaction.

Fault Handling Design Patterns

• In Screen Flows: Route the fault connector to a custom Screen Element. Display a polite, user-friendly explanation along with the global error variable {!$Flow.FaultMessage} so the user understands why the operation failed and what corrective action to take.
• In Record-Triggered & Autolaunched Flows: Route the fault connector to a Create Records element that inserts a detailed diagnostic record into a custom Error_Log__c object, capturing {!$Flow.FaultMessage}, {!$Flow.CurrentDateTime}, and the triggering record ID.
• The Custom Error Element: Introduced to provide declarative inline error handling. In Record-Triggered Flows, app builders can route fault paths or validation checks to a Custom Error element. This displays a targeted message and intentionally rolls back the triggering change. A log record inserted in that same transaction also rolls back; use a separately designed diagnostic channel if logs must survive.

---

Flow Testing, Debugging & Governance

Before deploying flows to production, app builders must rigorously verify their logic using Flow Builder's native testing and debugging tools:

1. The Debug Tool

Accessible from the top button bar, the Debug Tool executes the flow directly within Flow Builder and provides a detailed step-by-step execution log on the right side of the canvas. The debug panel displays exact variable values, decision path evaluations, SOQL query results, and governor limit consumption.

2. Run Flow as Another User

Administrators can check Run flow as another user within the Debug panel. This allows testing the flow under the specific security context, Profile, Permission Sets, and Sharing Rules of a target end user (e.g., a standard sales rep or external community user) without needing to log in as that user.

3. Rollback Mode

When testing flows that execute DML operations (Create, Update, Delete Records), checking Rollback Mode in the Debug tool executes all flow logic and logs all outcomes, but automatically rolls back all database modifications at the end of the debug run. This prevents dummy test records from cluttering the sandbox environment.

4. Declarative Flow Tests

Record-Triggered Flows feature a native View Tests panel that allows app builders to build and automate declarative test suites. Similar to Apex unit tests, Flow Tests define mock triggering records, set trigger conditions (create or update), and define Assertion criteria (e.g., verifying that after the flow executes, Opportunity.StageName equals Closed Won). These tests can be run on demand to protect against regression during deployments.

---

Bulkification Anti-Pattern vs. Enterprise Pattern

---

Best Practices & Common Exam Traps

Common Exam Traps

• Trap 1: Believing platform bulkification allows DML inside loops. Platform bulkification merges operations across separate record interviews in a batch; it does not bulkify elements repeated within a single interview's loop. DML inside a loop remains a fatal violation.
• Trap 2: Forgetting to clear single record variables in loops. When manually building new child records inside a loop using a single record variable, ensure you reset or clear the variable's fields before assigning new values, or create new items properly, to avoid duplicating stale data across records.
• Trap 3: Neglecting Fault Paths on external Actions. External HTTP callouts and invocable Apex actions are prone to network timeouts and service downtime. Leaving Action elements without fault paths causes unhandled transaction failures whenever external endpoints experience latency.

What Fault Handling Does Not Catch

Governor-limit exceptions are not recoverable through a fault connector: exceeding the transaction budget rolls back the transaction even if a connector is defined. For recoverable element errors, a handled fault can continue execution and commit earlier pending changes. Do not assume that displaying a Screen or creating a log undoes prior successful operations. Before deploying, test an intentional failure after an earlier write and verify the resulting database state.

Debug-as-another-user is available only in a sandbox after the org setting is enabled. System-context flows continue to bypass the user's CRUD/FLS even when a different running user is selected. Debug tests one flow path rather than the complete production save ecosystem; run representative sandbox transactions and bulk loads as well.

Official Source Check

Checked October 19, 2026: Flow transaction limits and rollback.