Study guide
6.4 Flow Execution Architecture, Bulkification & Fault Paths
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
6.4 Flow Execution Architecture, Bulkification & Fault Paths
Key Takeaways Explain This Topic AI
Flows are subject to standard platform governor limits, including 100 SOQL queries and 150 DML statements per synchronous transaction.
The golden rule of Flow design is to never place Data elements (Create, Update, Delete, Get Records) inside a Loop element.
Enterprise bulkification requires iterating over collections, modifying records via Assignment elements, adding to a new collection, and executing a single DML operation outside the loop.
Fault paths intercept runtime exceptions on Data and Action elements, enabling custom error logging, user-friendly notifications, or Custom Error element displays.
Flow debugging features include Run as Another User, Rollback Mode to prevent test data pollution, and declarative Flow Tests for regression protection.
Last updated: October 2026
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.
Caution
The Bulkification Illusion: While Salesforce automatically bulkifies data elements across multiple concurrent interviews , platform bulkification does NOT protect against poor design inside a single flow! If a single flow interview contains an unbulkified loop, the transaction will crash with governor limit exceptions.
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
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 ).
Initialize Target Collection Variable: Create an empty Record Collection Variable in the Manager tab (e.g., colRecordsToUpdate ).
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 ).
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' .
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} .
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
Architectural Feature Unbulkified Anti-Pattern (Failure) Enterprise Bulkified Pattern (Best Practice) Governor Limit Impact
SOQL Query Placement Get Records placed inside Loop Get Records executed once outside Loop 1 query vs. N queries (Exceeds 100 SOQL limit at 101 items)
DML Statement Placement Create / Update placed inside Loop Create / Update executed once outside Loop on Collection 1 DML vs. N DML (Exceeds 150 DML limit at 151 items)
In-Memory Collection Building Updating records individually Staging updates in a collection variable via Add operator Zero DML overhead during loop iterations
Transaction CPU Time High server roundtrips per item Single bulk database operation Eliminates excessive database context switches
Exception Handling No fault paths; unhandled system crash Fault path routes to Custom Error or Error_Log__c Clean user recovery and complete auditability
Best Practices & Common Exam Traps
Important
The Collection Add Operator: When appending a modified record to a Record Collection Variable inside a loop assignment, always use the Add operator ( {!colTarget} Add {!currentItem} ). Using the Equals operator will overwrite the entire collection with that single record, resulting in only the last processed item being saved!
Tip
Safe Rollback Mode for User Testing: Always activate Rollback Mode when debugging complex Record-Triggered Flows in sandboxes with active integrations. Database rollback cannot undo external callouts or work committed in earlier transactions. Use isolated test endpoints and mock actions where supported.
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 .