Beginner 20 min read

Loops and Governor Limits

By the end of this lesson, you'll be able to:

Explain what a governor limit is and why Salesforce enforces them
Identify the classic mistake of putting a database operation inside a loop
Recognize bulk-safe code versus code that will fail at scale

Prerequisites: "Break and Continue"

What a governor limit is

Salesforce is a multi-tenant platform — many companies\' code runs on shared servers. To stop one org\'s runaway code from degrading performance for everyone else, Salesforce enforces hard limits per transaction: for example, at most 100 DML statements (inserts/updates/deletes) and 100 SOQL queries. Exceed one, and Apex throws a LimitException and the whole transaction fails.

The classic mistake: DML or queries inside a loop

// DON'T DO THIS
for (Account acc : accountsToUpdate) {
    acc.Industry = 'Technology';
    update acc; // a separate DML statement on every single iteration!
}

This looks harmless for 5 accounts. With 200 accounts, it performs 200 separate update statements in one transaction — blowing past the 100-DML-statement limit and throwing an error that has nothing to do with the actual business logic.

The fix: bulkify — collect, then act once

List<Account> accountsToSave = new List<Account>();

for (Account acc : accountsToUpdate) {
    acc.Industry = 'Technology';
    accountsToSave.add(acc);
}

update accountsToSave; // one single DML statement, no matter how many accounts

The loop now only modifies records in memory and collects them into a list; the actual update happens exactly once, after the loop, regardless of whether there are 5 accounts or 5,000. This pattern — "collect inside the loop, act once outside it" — is called bulkification, and it's one of the most important habits in all of Apex development.

A real business example: E-commerce (Order Fulfillment)

List<Order__c> ordersToShip = [SELECT Id, Status__c FROM Order__c WHERE Status__c = 'Ready'];

for (Order__c ord : ordersToShip) {
    ord.Status__c = 'Shipped';
}

update ordersToShip; // one DML statement updates every order at once

A daily batch job marking every ready order as shipped might process thousands of records at once — exactly the scenario where a query or DML statement inside the loop would fail immediately, and bulkified code keeps working no matter the volume.

Exercise

The code below updates a Description field inside a loop with a DML statement on every pass. Rewrite it to be bulk-safe: collect the changes, then update once after the loop.

Show hint

Move `update acc;` outside the loop and add each acc to a List<Account> instead.

APEX

Loops and Governor Limits Quiz

1. Why does Salesforce enforce governor limits?

To stop one org's code from degrading shared, multi-tenant infrastructure for everyone else To make Apex harder to learn To limit how many developers can work on an org To slow down all code equally

2. What is "bulkification"?

Collecting changes inside a loop and performing DML once, outside it Putting a DML statement inside every loop iteration Writing loops without any conditions A type of governor limit

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

Salesforce runs on shared infrastructure, so every org's code is capped by governor limits — hard ceilings on things like database queries and DML statements — and loops are where those limits get hit hardest.

← Break and Continue Plan the Program →