Understanding Salesforce Flow Governor Limits: A Complete Guide

Every Salesforce developer and admin dreads the same error: "Too many SOQL queries: 101". Governor limits are Salesforce's way of ensuring the multi-tenant architecture remains stable—but they can trip up even experienced professionals.

This guide explains the key governor limits that affect Salesforce Flows and how to stay under them.

What Are Governor Limits?

Governor limits are runtime constraints that Salesforce enforces on all code execution. They prevent any single transaction from:

• Monopolizing shared resources
• Causing performance issues for other tenants
• Running indefinitely

These limits apply to:

• Apex code
• Flows
• Process Builder (deprecated)
• Workflow Rules

Key Governor Limits for Flows

1. SOQL Query Limit

Limit: 100 queries per transaction

Each Get Records element in your flow counts as one SOQL query.

How to avoid:

• Never put Get Records inside a loop
• Combine related queries into one
• Use formulas to access parent data
• Filter with entry conditions

2. DML Statement Limit

Limit: 150 DML statements per transaction

DML operations include:

• Create Records
• Update Records
• Delete Records

How to avoid:

• Collect records in a collection variable
• Perform single DML outside loops
• Use the "Update Records" element with multiple records

3. CPU Time Limit

Limit: 10,000ms (10 seconds) for synchronous transactions

Complex flow logic consumes CPU time:

• Large loops
• Many decision elements
• Complex formulas

How to avoid:

• Simplify logic where possible
• Move complex processing to async Apex
• Limit loop iterations

4. Heap Size Limit

Limit: 6 MB for synchronous transactions

Heap size is the memory used by your transaction:

• Large collections
• Text fields with lots of data
• Recursive flows

How to avoid:

• Limit collection sizes
• Query only needed fields
• Avoid storing unnecessary data

5. Same-Object Recursion

Limit: 2 levels of flow recursion per object

Record-triggered flows can cause recursion when:

• Flow A updates Record → triggers Flow B
• Flow B updates same Record → triggers Flow A again

How to avoid:

• Use $Record__Prior to check if field changed
• Add recursion prevention logic
• Use "Run one per record" setting

Common Scenarios That Hit Limits

Scenario 1: The Loop Query Problem

❌ Bad Pattern:

For each Account in accountCollection:
  → Get all Contacts for this Account
  → Update Contacts

Why it fails: 100 accounts = 100 queries = LIMIT HIT

✅ Good Pattern:

Get all Contacts where AccountId IN accountCollection
For each Contact:
  → Add to updateCollection
Update Records: updateCollection

Scenario 2: Too Many Record Updates

❌ Bad Pattern:

For each Lead in leadCollection:
  → Update Lead record

Why it fails: 200 leads = 200 DML = LIMIT HIT

✅ Good Pattern:

For each Lead in leadCollection:
  → Modify Lead record
  → Add to updateCollection
Update Records: updateCollection (single DML)

Scenario 3: Screen Flow with Multiple Screens

The Issue:

Each screen submission may restart flow processing.

Solution:

• Batch data lookups at the start
• Store in collection variables
• Reference cached data in subsequent screens

How FlowDocs Helps

FlowDocs automatically scans your flows for governor limit risks:

✅ DML in loops detection

✅ SOQL in loops detection

✅ Missing fault paths

✅ Hard-coded IDs

✅ Complexity scoring

Our risk analysis gives you a clear view of potential issues before they hit production.

Debugging Governor Limit Errors

When you hit a limit:

1. Enable Debug Logs
2. Setup → Debug Logs
3. Add your user
4. Execute the flow

1. Analyze the Log
2. Search for "LIMIT" in the log
3. Count SOQL and DML operations
4. Identify the problematic element

1. Use Flow Debug
2. Debug button in Flow Builder
3. Shows execution path
4. Displays query/DML counts

Governor Limits Quick Reference

Best Practices Summary

1. Query Smart
2. Get only fields you need
3. Filter in the element, not in logic
4. Never query in loops

1. Bulk Your DML
2. Collect records in collections
3. Single DML outside loops
4. Use Update Records with collections

1. Monitor Regularly
2. Review flow complexity
3. Check debug logs periodically
4. Use tools like FlowDocs for analysis

1. Design for Scale
2. Consider data volumes
3. Test with bulk data
4. Plan for growth

Conclusion

Governor limits aren't obstacles—they're guardrails that encourage efficient design. By understanding these limits and following best practices, you can build flows that scale to any data volume.

Remember: A flow that works with 10 records but fails with 100 is a flow that will eventually fail in production.

Related Articles:

• Salesforce Flow Best Practices: The Complete Guide
• How to Document Salesforce Flows Automatically
• Salesforce Flow Naming Conventions: A Complete Guide