04.04.01 — Governor Limits, Bulkification, and Performance Risk

Lesson goal

This lesson explains why Governor Limits are a critical QA concern, not just a developer problem.

After completing this lesson, you should be able to:

• understand how Salesforce Governor Limits impact integrations and automation
• design bulk tests that expose non-bulkified logic
• detect inefficient SOQL and DML usage
• identify CPU time and memory risks before production
• classify performance defects correctly by severity

This lesson opens the Performance and Scalability section of Module 4.

The problem: shared resources and hard limits

Salesforce runs on a multitenant architecture.
Every org shares CPU, database, and memory resources with other customers.

To protect platform stability, Salesforce enforces hard Governor Limits.

For QA, this becomes critical when dealing with:

• data migrations
• integrations
• batch operations
• high-volume automation

A solution that works perfectly for a single record can fail catastrophically under load.

Why integrations fail first

Integrations amplify performance risk.

Inbound risk

• bulk loads from ERP or external systems
• mass updates through APIs
• scheduled sync jobs

Common failures:

• Too many SOQL queries
• Too many DML statements

Outbound risk

• Apex callouts triggered per record
• unhandled exceptions inside loops
• slow response handling

One failure can roll back an entire transaction affecting hundreds of records.

Critical performance testing areas

QA performance testing must focus on scenarios that stress platform limits.

Bulkification testing (the 200-record rule)

Salesforce processes up to 200 records per transaction.

All automation must be able to handle this volume safely.

Apex bulk test

• Action: Use Data Loader to insert, update, or delete 200 records in one operation.
• Expected result:
  The transaction completes successfully for all records.

If the system throws:

• Too many SOQL queries
• Too many DML statements

the logic is not bulkified and the defect is critical.

Flow bulk test

• Trigger a record-based Flow with a 200-record batch.
• Verify the Flow executes successfully without limit exceptions.

Flows are subject to the same limits as Apex.

SOQL queries and loop detection

The most common governor limit failure is querying inside a loop.

The loop test

• Scenario: Integration logic runs when Accounts are updated.
• Action: Update 10 records in one transaction.
• Expected result:
  The total SOQL query count should be significantly less than 10.

If each record triggers its own query, the code will fail at scale.

This is a performance defect, not a functional one.

CPU time and memory constraints

Complex logic increases CPU and heap usage.

High-risk scenarios include:

• large JSON payload parsing
• deep object hierarchies
• complex calculations
• recursive automation

Load test with complex data

• Action: Trigger automation using records with:
• maximum text field length
• many related child records
• Expected result:
  The transaction completes without:
• Apex CPU time limit exceeded
• heap size exceptions

Failures indicate scalability risk.

Practical QA performance strategy

Three-step integration performance test

Always test integrations using three volumes:

1. Single record (1×)
   Confirms functional correctness.
2. Maximum transaction size (200×)
   Confirms bulkification.
3. Expected business volume (e.g. 2000×)
   Confirms stability over multiple transactions.

Skipping step 2 guarantees production failures.

Using debug logs for limit verification

Debug Logs provide direct visibility into governor limit usage.

What to check

• SOQL queries: low usage count
• DML statements: minimal operations
• CPU time: safe margin under limits

Any logic approaching limits under normal load must be treated as high risk.

Defect classification

Performance and governor limit defects should be classified as:

• High severity
• Release blockers
• Non-negotiable fixes

A non-bulkified integration will fail as soon as real business data is processed.

Summary

Governor Limits define the scalability boundary of Salesforce solutions.

From a QA perspective:

• performance testing is mandatory for integrations
• bulkification must be validated explicitly
• limit violations are predictable and preventable
• debug logs are a core QA diagnostic tool

By testing bulk behavior early and aggressively, QA prevents silent failures, data loss, and production outages caused by limit violations.

What’s next

In the next lesson, we connect performance with data consistency:
04.04.02 — Data Volume, Archiving, and Long-Term Performance Risk