Salesforce Flow has become the primary automation tool on the Salesforce platform. Organizations use Flow to automate approvals, integrations, notifications, and complex business processes without writing code.

However, every Flow runs on Salesforce’s multitenant platform and is subject to governor limits.

If you’ve ever seen errors like:

Too many SOQL queries: 101

or

Apex CPU time limit exceeded

you’ve already encountered governor limits.

Understanding these limits is essential because poorly designed Flows may work perfectly in testing but fail when processing larger amounts of data in production.

In this guide, we’ll explain Salesforce Flow governor limits, how they work, common mistakes, and best practices for building scalable automations.

What Are Salesforce Governor Limits?

Salesforce is a multitenant platform where thousands of organizations share the same infrastructure. To prevent one organization from consuming excessive resources, Salesforce enforces governor limits on transactions.

Governor limits protect:

• platform performance
• database resources
• application stability
• fair resource consumption

Official documentation

Flow considerations

Do Salesforce Flows Have Governor Limits?

Yes.

Although Flow is a low-code tool, it still runs on the Salesforce platform and consumes the same underlying resources as Apex.

This means Flows can hit limits related to:

• SOQL queries
• DML statements
• CPU time
• query rows
• records processed

Understanding these limits becomes increasingly important as automation grows.

Flow Interview vs Transaction

This is one of the most misunderstood concepts in Salesforce Flow.

Flow Interview

A Flow Interview is one execution of a Flow.

For example:

200 records inserted
↓
200 Flow Interviews created

Transaction

A transaction is a unit of execution on the Salesforce platform.

Governor limits apply to transactions, not individual Flow interviews.

This means:

200 Flow Interviews
≠
200 separate governor limit sets

Many Flow interviews may run inside the same transaction and share the same limits.

Understanding this concept is critical when working with bulk operations and data imports.

Wait Elements Create New Transactions

Certain Flow elements end the current transaction and start a new one.

Examples include:

• Screen elements
• Pause elements
• Wait for Conditions
• Wait Until Date

When a new transaction starts, governor limits reset.

This is an important design technique for long-running business processes and large-scale automations.

How Salesforce Flow Bulkification Works

Many administrators assume this:

200 records imported
=
200 SOQL queries

This is incorrect.

Salesforce automatically attempts to bulkify many Flow operations.

Example:

200 records inserted
↓
200 Flow Interviews
↓
Get Records executes in bulk
↓
Update Records executes in bulk

However, poorly designed automations can still exceed governor limits.

Understanding bulkification is essential when building record-triggered Flows that process large amounts of data.

Record-triggered Flow considerations

The Most Important Salesforce Flow Governor Limits

Official reference

DML Record Limit

A single transaction can process up to:

10,000 records

created, updated, or deleted.

This limit is commonly reached during:

• large data migrations;
• integrations;
• bulk updates;
• scheduled automations.

A Flow may contain only a few Update Records elements and still exceed this limit if too many records are processed.

Common Salesforce Flow Governor Limit Errors

Common Causes of Governor Limit Problems

Too Many Automations on One Object

A single update may trigger:

• Record-Triggered Flows
• Apex Triggers
• Validation Rules
• Process Builder
• Assignment Rules

All of these consume resources within the same transaction.

Processing Large Data Volumes

Many Flows work perfectly with:

• 10 records;
• 100 records;
• 500 records.

Then fail when processing thousands of records.

Excessive Get Records Elements

Each query consumes resources.

Multiple unnecessary queries can quickly lead to limit issues.

Recursive Automation

Flow updates a record.

The update retriggers another Flow.

The cycle repeats until governor limits are exceeded.

Complex Automation Architecture

Too many interconnected automations often create CPU issues.

Historical Flow Element Limit

You may still find references online to the following limit:

2,000 executed elements

This limit existed in older Flow versions.

Beginning with newer API versions, Salesforce removed this restriction.

However, this does not mean Flow performance is unlimited.

Large and overly complex Flows can still negatively affect CPU time and transaction performance.

Governor Limits During Data Imports

Data imports are one of the most common causes of Flow failures.

Tools such as:

• Data Import Wizard
• Data Loader
• Bulk API

typically process records in batches.

For example:

200 records
↓
One transaction
↓
Shared governor limits

This is why poorly designed automations often fail during data migrations while working perfectly during normal user activity.

Schedule-Triggered Flow Limits

Schedule-triggered Flows also have platform limits.

Organizations can run up to:

250,000 scheduled interviews per 24 hours

or:

number of user licenses × 200

whichever is greater.

Schedule-triggered Flows can query a maximum of:

50,000 records

and process records in batches of:

200 records

For very large data volumes, Batch Apex may be a better solution.

Official documentation

Warning Signs That Your Flow Will Hit Governor Limits

Your Flow is likely to encounter governor limits if you see:

• multiple automations on one object;
• complex recursion;
• long execution times;
• frequent CPU errors;
• data loads failing;
• many subflows;
• thousands of records processed in one transaction.

Salesforce Flow Governor Limit Best Practices

Use Entry Criteria

Avoid running Flows unnecessarily.

Reduce Record Updates

Only update records when data actually changes.

Consolidate Automations

Fewer automations usually mean lower transaction complexity.

Avoid Recursive Design

Prevent Flows from continuously updating the same records.

Use Collections

Collections allow records to be processed more efficiently.

Optimize Get Records

Only retrieve the fields you need.

Avoid unnecessary queries.

Design for Large Data Volumes

Always ask:

What happens if this Flow processes 10,000 records?

Monitor CPU Consumption

CPU time is often the first limit organizations encounter as automation grows.

Use Asynchronous Processing When Appropriate

Scheduled Paths and asynchronous techniques can reduce transaction complexity.

Use Apex for Complex Scenarios

Some problems simply exceed what Flow was designed to handle.

How to Troubleshoot Governor Limit Errors

Useful tools include:

• Flow Debug
• Debug Logs
• Error Emails
• Failed Interviews
• Monitoring Reports

Related reading:

Salesforce Flow Error Handling Best Practices

When Should You Use Apex Instead of Flow?

Consider Apex when you need:

• advanced calculations
• complex integrations
• massive data processing
• sophisticated error handling
• highly optimized performance

Related article:

Salesforce Flow vs Apex: When to Use Each Approach

Salesforce Flow Governor Limits Checklist

• Understand transaction boundaries.
• Understand Flow bulkification.
• Reduce unnecessary automations.
• Avoid recursive design.
• Monitor CPU usage.
• Optimize Get Records elements.
• Design for large data volumes.
• Test with realistic data.
• Use asynchronous processing when necessary.
• Move complex logic to Apex when appropriate.

How Success Craft Can Help

Building scalable automation requires more than simply creating Flows.

At Success Craft, we help organizations:

• design scalable automation architectures;
• optimize Salesforce performance;
• troubleshoot governor limit issues;
• implement enterprise-grade Flow solutions.

Related resources:

Salesforce Flow Best Practices

10 Common Salesforce Flow Mistakes (and How to Avoid Them)

Salesforce Flow Error Handling Best Practices

Salesforce Consulting Services

Contact Us

Conclusion

Governor limits are not restrictions designed to make development difficult.

They are safeguards that help Salesforce maintain performance and stability across its multitenant platform.

Understanding transactions, bulkification, and platform limits is essential for building scalable, reliable, and high-performing automations.

The best Salesforce automations are not only functional—they are designed to scale as your business grows.