Optimizing Salesforce Flows: Lessons from a 100k-Record Migration

Salesforce Flow is incredibly powerful, enabling developers and administrators to build complex automation logic without writing code. However, as your data scales, unoptimized Flows will quickly run into **Apex CPU Time Limit Exceeded** errors or **SOQL Query Limit** exceptions. During a recent database migration, we had to process over 100,000 active account records. Standard active flows immediately broke down. Here are three critical rules we applied to optimize the architecture and keep the migration running. ### 1. Avoid Database Queries (SOQL) Inside Loops This is the golden rule of CRM database design. Placing a "Get Records" or "Update Records" element inside a Loop element consumes a database transaction query for each iteration. Under bulk data changes, this immediately hits the 100-query limit. - **Bad Pattern**: Loop -> Get Related Record -> Update Loop Item -> Repeat. - **Good Pattern**: Get all related records *before* entering the loop, filter them inside variables using collection filters, build a collection of records to update inside the loop, and execute a single bulk update *after* the loop completes. ### 2. Leverage Fast Field Updates (Before-Save Flows) If your flow is modifying fields on the *same record* that triggered it, always use **Before-Save optimization** (Fast Field Updates). Before-save flows execute before the record is saved to the database. This bypasses the heavy Salesforce save execution cycle, running up to **10 times faster** than standard record-triggered flows. ### 3. Decouple Processes with Asynchronous Paths For automations that send emails, fetch geo-coordinates from external APIs, or sync records with ERP databases, do not force users to wait for these actions to complete synchronously. Enable the **Run Asynchronously** path on your Record-Triggered Flows. This allows the primary database write to finish instantly while queuing the heavy external actions to process in the background.