Free Sample Lesson: Multitenancy and Governor Limits (Platform Developer Cert Lab)

Free sample lesson from the Platform Developer Cert Lab. The full course has 21 lessons and 370 practice questions.

Developer Fundamentals · DF1 · part of the 27% section · about 20 min with practice

DF1: Multitenancy and governor limits

You’ll be able to: explain why a multitenant platform enforces governor limits, recall the per-transaction limits the exam leans on, and spot code that will hit them.

Per-transaction limits: which one bites when

Limit	Synchronous	Asynchronous	Typical cause
SOQL queries issued	100	200	A query inside a for loop
Records retrieved by SOQL	50,000	50,000	Querying a whole large object
DML statements issued	150	150	An insert or update inside a loop
Records processed by DML	10,000	10,000	One huge DML list
CPU time on Salesforce servers	10,000 ms	60,000 ms	Heavy loops and processing

Multitenancy in one sentence

Salesforce is like an apartment building: your company has its own space, but you share computing power, data storage and core features with every other customer. That sharing is multitenancy, and it’s also why everyone gets the same upgrades without installing anything.

Why limits exist

Apex is multitenant aware. Because it runs on shared resources, the Apex runtime engine strictly enforces governor limits so runaway code can’t monopolize them. Limits are counted per transaction. When code exceeds one, the governor throws a runtime exception that can’t be handled: no try/catch saves you. The only fix is code that stays inside the limits.

The two habits that prevent most limit errors

1. DML on lists, not single records. The Apex Developer Guide shows a loop that updates one line item per iteration: with more than 150 items, the 151st update throws. The fix collects records in a list and updates once:

List<Line_Item__c> updatedList = new List<Line_Item__c>();

for (Line_Item__c li : liList) {
    if (li.Units_Sold__c > 10) {
        li.Description__c = 'New description';
        updatedList.add(li);
    }
}

// One DML call for the entire list of line items
update as user updatedList;

2. SOQL outside loops. A query inside a loop over Trigger.new runs once per record, so more than 100 records breaks the 100-query limit. Query once with WHERE Id IN :Trigger.newMap.keySet() and use a nested subquery for child rows. To handle large result sets, a SOQL for loop processes records in batches of 200.

One more detail: in a query with parent-child subqueries, each parent-child relationship counts as an extra query.

Exam trap

“Wrap it in try/catch” is the wrong fix for a governor limit. Limit exceptions can’t be handled; you have to bulkify the code. Also watch the sync vs async numbers: 100 SOQL queries is the synchronous limit, 200 is asynchronous.

Predict, then reveal

A trigger loops over Trigger.new and runs one SOQL query per record. A data load inserts 150 records in one transaction. What happens?

Show the answer

It fails. The 101st query exceeds the synchronous limit of 100 SOQL queries, and the exception can’t be caught.

Try it 5 min · your free Developer Edition org

In your Developer Edition org, open the Developer Console and choose Debug > Open Execute Anonymous Window.
Paste a loop that builds a List<Account> of 3 new accounts and calls insert once after the loop, then click Execute.
Open the Query Editor tab and run SELECT Name FROM Account ORDER BY CreatedDate DESC LIMIT 3. Result: your 3 accounts appear in Query Results, saved with one DML statement.

Practice questions

Ten exam-style questions on this lesson. Answer each one before you open it.

Question 1. A trigger runs one SOQL query for each record in Trigger.new. What’s the largest synchronous batch it can handle before failing on queries alone?

A. 150 records
B. 100 records
C. 200 records
D. 50,000 records in a single run