Governor Limits

Governor limits are the caps Salesforce applies to each code and automation transaction to prevent a process from consuming more resources than its share. Because Salesforce is a multi-tenant platform (many organizations share the same infrastructure), these limits ensure that one company's code never degrades performance for everyone else. They are one of the first constraints anyone programming on Salesforce runs into.

Unlike your own server, where you can consume CPU or memory until the machine runs out, on Salesforce every transaction starts with a fixed budget of resources. If your code exceeds that budget (for example, more than 100 synchronous SOQL queries or more than 150 DML operations), the platform stops execution and throws an exception that cannot be caught and ignored. The limit is neither optional nor configurable: it is part of the platform's contract.

That is why, in the Salesforce world, writing good code is not just about making it work but about making it work within the limits even as data volume grows. Designing with governor limits in mind is the difference between an automation that holds up under ten thousand records and one that blows up at the first large batch.

Why governor limits exist

Salesforce does not give you a dedicated server: your organization lives on infrastructure it shares with thousands of other customers. That multi-tenant model is what makes the platform affordable and scalable, but it introduces a risk: if a single company could run a giant query or an infinite loop, it would slow down everyone else. Governor limits are the mechanism that distributes resources fairly. In essence, they are a per-transaction budget: every time your code runs (a trigger, a flow, an API call), Salesforce measures how many queries, records, external calls and CPU time you consume, and stops execution as soon as you go over the cap.

The most important limits

Although there are dozens, in practice most problems come from a handful of per-transaction limits. These are the ones you run into most often in real projects:

• SOQL queries: 100 in synchronous context, 200 in asynchronous. Every time you request data from the database, it counts as a query.
• Records retrieved by SOQL: up to 50,000 in total within the transaction.
• DML operations: 150 statements (insert, update, delete) per transaction.
• Records processed by DML: 10,000 in total.
• CPU time: 10,000 milliseconds in synchronous context (the one that surprises people most, because heavy logic burns through it fast).
• Calls to external services (callouts): 100 per transaction, with a cap on total time.
• Heap (memory): 6 MB synchronous, 12 MB asynchronous.

Bulkification: the golden rule

The most common mistake of someone new to Salesforce development is writing code that runs a query or a DML operation inside a loop. If you process 200 records and query the database once for each one, you reach 200 queries and go over the limit of 100. The solution, called bulkification, is to move queries and DML out of the loop: a single query that brings everything you need at once, and a single DML operation that writes the complete list. Designed correctly, a trigger that processes 1 record or 200 consumes exactly the same number of queries. This practice is not optional: it is the correct way to write code on the platform.

A concrete example (Argentina)

Think of a consumer goods distributor that imports 5,000 orders every night from its legacy system into Salesforce. A trigger on Order recalculates the customer's account balance every time a record comes in. If that trigger queries the account one by one, processing the batch of 5,000 exceeds the query limit and the entire integration fails at 3 a.m., leaving data half written. Rewritten with bulkification (one query that brings all the affected accounts and a single bulk update), the same process runs without getting close to any cap. It is the typical case where the difference between knowing and not knowing about governor limits costs a night of incidents.

Common mistakes

• Running SOQL or DML inside a for loop (one of the most frequent causes of exceeded limits).
• Testing with 1 or 2 records and assuming it scales: the limits only show up with volume.
• Chains of automations (a flow that fires a trigger that fires another flow) that add up CPU and DML without anyone seeing them together.
• Uncontrolled recursion: an update that triggers itself and burns through the budget.

Governor limits vs multi-tenancy

People often confuse the limit with the architecture that justifies it. They are not the same:

In short, multi-tenancy is the cause and governor limits are the consequence: because you share infrastructure, the platform needs limits so the distribution is fair. Understanding this changes the way you design: on Salesforce you do not program against a machine, you program against a budget, and respecting it is the foundation of any integration or automation that aims to hold up under real volume.