Salesforce consulting that maximizes results.

Bulkifying Flows to Avoid Governor Limits

New Apex developers quickly learn the ins and outs of governor limits and good coding practices to “bulkify” code.

Similar to coding, you can create a flow quick and easy without regard for governor limits, or you can apply some good practices to avoid them.

This quickly becomes apparent and important and when you are mass updating records which trigger autolaunched flows (formerly “headless” and “trigger-ready” flows).

This can lead to the “Too many SOQL queries: 101” error.

Too many SOQL queries: 101

Too many SOQL queries: 101

Administrators might take to the habit of deactivating and reactivating flow triggers for every code deployment or data load, or reducing batch size. But we quickly get tired of this exercise (not to mention the risk of accidentally leaving a flow trigger off).

Not to mention, there are going to be process automation instances that trigger multiple flows and you will want to ensure they don’t trigger limits.

So, what should we do?

Limit the conditions that fire the Flow

Limiting the conditions that fire the flow is the quickest and easiest way to start to bulkify a Flow.

We often see experienced developers write workflow rules that fire every time a record is edited. For example, when created date not null.

However, if your workflow rule is going to fire an autolaunched flow, be as specific as reasonably possible in configuring the formula.

Specific workflow rule criteria

Specific workflow rule criteria

Fast Elements – working with “collections”

When coding in Apex, you tend to work with “lists” (also known as “arrays” or “collections”). Good coding practices load records into memory as lists, perform logic on the sObjects, then commit the record updates to the database. This exercise can be done with two SOQL queries (the lookup and the commit), while also performing complex logic on the records while they are in memory.

Extending this logic to flows, the equivalent is the “fast ” elements. Fast Lookup can create a collection of sObjects in memory, Fast Update can commit a collection to the database, etc.

To bulkify flows, we want to use the fast elements whenever possible to act on a collection of sObjects.

Watch out for Loops

If you have a Record Create, Record Update or Record Delete element inside of a loop, it fires a SOQL query for item in the collection that you are looping through.

Bad: one Record Create query for each item in the loop

Bad: one Record Create query for each item in the loop

A better approach is to create the collection (likely via a Fast Lookup), loop through the sObjects performing your updates using the Assignment Element (and possibly formulas), and finally commit the sObjects to the database using Fast Update/Create/Delete when you’re ready to commit them.

Better: perform Assignments in memory, then commit to the database

Better: perform Assignments in memory, then commit to the database

Decisions – Check Before You Update

Before committing an update to the database, use a Decision Element to see if it needs to be done.

For example, say we look up fields on an Account and its Opportunities and determine it is a “prospect”. Before we set a picklist value as “Prospect”, we use the Decision Element to see if it is already set as Prospect, which could save one SOQL update query.

Decision: field already set, before we set it?

Decision: field already set, before we set it?

Apex bulkifying Features Not Available in Flows

If you are maxing out your SOQL governor limits with flows (using the above guidance) and it is vital functionality, there are extra features you can gain by converting to Apex.

Loading sObjects with Complex Criteria

Within flows, the search methods to create your sObject collection is very rudimentary.You can use either “And” logic or “Or” logic to create an sObject collection.


If you need more complex criteria, you have to break the search into components, perform multiple lookups, then loop through your result sets to add them to a single collection – requiring multiple SOQL queries.

If you are aware of a better method, please let us know!

Creating a single collection from five different queries

Creating a single collection from five different queries

Within Apex, you can write more dynamic criteria in a single SOQL query (for example, nesting a SELECT statement in the WHERE clause of another SELECT query.

More flexibility with SOQL queries

More flexibility with SOQL queries

Batch Apex

Apex uses the Database.Batchable interface which allows you to place jobs in the Apex job queue for execution, with a batch size is 200 records.

Flows are “All or None”

If you hit an error or a governor limit within a Flow, the entire instance of that flow fails.

Again, using the Apex Database class, you can set “opt_allOrNone” argument to false which will allow partial success.


For small, lightweight flows that are always triggered by user interaction (for example, flows that are not autolaunch flows), you will likely be okay using Record Create, Update, etc. Elements without too much consideration for governor limits.

However, if it’s an autolaunched flow that will likely be triggered by batches, performs a lot of updates or has loops, you are going to want to be very cognizant of bulkifying your flow and maintain close adherence to good practices.

Then there are going to be instances where you have stretched the ability of Flows. You will want to consider Apex development, or even manual options.

Leave a Reply

Contact Info

  +1 (403) 815-1550
Calgary AB Canada

Customer Testimonials

  • "We are extremely satisfied their services [...]"
  • "They are a great company to work with [...]"
  • See more


Salesforce,, and are trademarks of and are used here with permission.