Salesforce Flow bulkification: How to handle bulk records

Why Salesforce Flow bulkification is non-negotiable

If you've been working in the ecosystem for more than a week, you've probably heard about Salesforce Flow bulkification. It's one of those things that sounds like jargon until your Flow crashes because a data import hit a governor limit. I've seen teams build beautiful logic that works perfectly for a single record, and the second a user tries to mass-update 200 records, the whole thing falls apart.

Salesforce processes record-triggered Flows in batches. If your Flow isn't designed to handle those batches efficiently, you'll hit SOQL or DML limits faster than you can say "System.LimitException". When I first started with Flows, I made the mistake of thinking the system would just "handle it" for me. It doesn't. You have to design for the batch from the start.

Performance is the other half of it. A well-built Flow keeps the UI snappy for your users and prevents those annoying "Apex CPU time limit exceeded" emails that haunt every admin's inbox. If you follow some basic best practices for Salesforce Flow, you'll save yourself a lot of late-night debugging.

Salesforce Flow Builder showing a bulkified automation with the data elements placed outside the loop.

The blueprint for Salesforce Flow bulkification

It's mostly about where you put your elements and how you handle data. Most people get into trouble because they think record-by-record instead of collection-by-collection. Here are the rules I live by when building any automation.

1) The golden rule: no SOQL or DML in loops

This is the most common mistake I see. Never, ever put a "Get Records", "Update Records", or "Create Records" element inside a Loop. If you have a loop that runs 50 times and an update sits inside it, that's 50 DML statements. If two people trigger that Flow at the same time, you're toast.

Instead, use an Assignment element to add your modified records to a collection variable. Then, once the loop is completely finished, perform one single "Update Records" operation on that entire collection. That one move is most of what bulkification means in Flow.

2) Get comfortable with the Transform element

I used to spend way too much time building loops just to map fields from one object to another. But honestly, the Transform element has changed how I handle data mapping. It's much cleaner than a loop with five assignments inside it. You map source fields to target fields visually and it handles the collection logic behind the scenes.

3) Use Before-Save Flows for simple updates

If you only need to update fields on the record that triggered the Flow, use a "Fast Field Update" (before-save). These are incredibly efficient because they don't trigger an extra DML statement. They happen before the record is even saved to the database. I always tell my juniors: if you aren't touching related records or sending emails, go with before-save.

Pro tip: If you find yourself hitting CPU limits even with bulkified logic, check your record-triggered flows. Sometimes a simple field update is better handled in a before-save flow to skip the entire save-order overhead.

4) When to bring in Invocable Apex

Flow is powerful, but it isn't always the right tool for heavy lifting. If you're dealing with complex math, deep nested loops, or thousands of records, you might need to call an Apex action. Just make sure your Apex is also bulk-safe. Here is a simple pattern I use for processing account data in bulk:

public with sharing class FlowBulkProcessor {
    @InvocableMethod(label='Update Account Values')
    public static void updateAccounts(List<Id> accountIds) {
        List<Account> toUpdate = [SELECT Id FROM Account WHERE Id IN :accountIds];
        for (Account acc : toUpdate) {
            acc.Description = 'Updated via Flow and Apex';
        }
        update toUpdate;
    }
}

Notice how the method takes a List of IDs? Flow passes a list of inputs when multiple records trigger the action at once. You have to write your code to handle that list, or you'll just end up with the same limit problems you were trying to avoid.

5) Error handling and async paths

One thing that trips people up is what happens when one record in a batch fails. By default, the whole transaction rolls back. I like to use Fault Paths to catch errors and log them to a custom "Error Log" object. That way I can see exactly what went wrong without the user getting a generic "An unhandled fault has occurred" message.

Now, if you're doing something really heavy, like calling an external API, you should use an Asynchronous Path. This moves the work to a separate thread so the user doesn't have to wait for the process to finish. It's one way of staying under limits while still getting the work done.

Key takeaways

• Never query or update inside a loop. Use collection variables and perform DML at the very end.
• Use Fast Field Updates for any change happening on the triggering record itself.
• Reach for the Transform element instead of manual looping for data mapping.
• Assume your Flow will be triggered by 200 records at once, not just one.
• If the logic gets too messy in Flow, move it to an Invocable method.

Wrapping up

Bulkification comes down to respecting the governor limits and treating every input as a potential batch of data. Start by moving those DML elements out of your loops, and you'll already be ahead of most people.

Next time you build a Flow, try running a bulk test with a few hundred records in a sandbox. It's much better to find a limit issue there than to have your boss call you on a Friday afternoon because the "New Lead" process is broken for the entire sales team. Trust me, I've been there, and it's not fun.