Governor Limits in Salesforce

If you’re new to Salesforce development, one of the first concepts you’ll come across is Governor Limits. These limits are crucial to understand because they affect how your code runs within the Salesforce platform. In this article, we’ll break down governor limits in an easy-to-understand way, starting with Salesforce’s multitenant architecture and why these limits are essential.

What is a Multitenant Architecture and How Does Salesforce Use It?

Salesforce operates on a multitenant architecture. This means that multiple organizations (or “tenants”) share the same physical infrastructure, such as servers, databases, and resources. However, even though multiple customers are sharing this infrastructure, they are isolated from each other in terms of data and customization. This is like living in a big apartment building where everyone has their own space but shares the same foundation, plumbing, and electricity.

Why Salesforce Uses Multitenant Architecture

  • Cost-Efficiency: By sharing resources, Salesforce can provide its platform to millions of users at a lower cost.
  • Scalability: Salesforce can scale its platform efficiently by using shared infrastructure.
  • Continuous Updates: Salesforce can deliver platform updates to all users simultaneously, ensuring everyone has access to the latest features and security enhancements.

However, with so many users sharing the same infrastructure, Salesforce needs to ensure that one tenant (or organization) doesn’t use too many resources and affect the performance of others. This is where Governor Limits come into play.

What Are Governor Limits and Why Does Salesforce Need Them?

Governor Limits are restrictions enforced by Salesforce to ensure that no single organization can monopolize shared resources like CPU time, memory, and database space. These limits ensure the platform runs efficiently and fairly for everyone.

Without these limits, a poorly written or overly complex piece of code could consume too many resources, slowing down the platform or even causing it to crash for others. Governor Limits make sure that Salesforce remains fast and reliable for all users.

Example:

Imagine you’re in a shared apartment complex, and everyone uses the same water supply. If one person uses all the hot water, no one else can take a warm shower. Governor Limits are like rules to ensure everyone gets a fair share of resources.

Different Types of Governor Limits in Apex

In Apex (Salesforce’s programming language), there are several different types of governor limits. Let’s go through the most important ones and explain what they mean.

1. SOQL Query Limits

  • SOQL (Salesforce Object Query Language) is used to query records from the database.
  • Governor Limit: You can execute 100 SOQL queries per transaction.
  • Why It Matters: Every time you run a SOQL query, Salesforce counts it towards your limit. If you exceed this limit, your code will throw an error, and the transaction will fail.
List<Account> accList = [SELECT Id, Name FROM Account LIMIT 50];

This is 1 query towards your SOQL limit.

2. DML Statement Limits

  • DML (Data Manipulation Language) statements include insert, update, delete, undelete, and merge operations.
  • Governor Limit: You can perform 150 DML statements per transaction.
  • Why It Matters: Each DML operation counts towards this limit. If you have too many DML operations in your code, it could exceed the limit, causing the transaction to fail.
Account acc = new Account(Name = 'New Account');
insert acc;  // 1 DML statement

3. CPU Time Limit

  • This limit restricts how long your Apex code can run.
  • Governor Limit: Your code can use a maximum of 10,000 milliseconds (10 seconds) of CPU time per transaction.
  • Why It Matters: If your code runs inefficiently or contains loops that take too long, it might exceed this limit, causing the transaction to fail.
// Inefficient code with a loop
for (Integer i = 0; i < 1000000; i++) {
    // Some operation
}

This could easily exceed the CPU time limit.

4. Heap Size Limit

  • Heap size refers to the amount of memory your code can use to store variables and objects.
  • Governor Limit: You are allowed 6 MB of heap size in synchronous transactions and 12 MB in asynchronous transactions.
  • Why It Matters: If you store too much data in memory (like large lists or objects), your code could run out of space and hit this limit.
List<String> largeList = new List<String>();
for (Integer i = 0; i < 1000000; i++) {
    largeList.add('Item ' + i);
}

This could lead to a heap size limit error.

5. Callout Limits

  • Callouts are external requests made from Salesforce to other systems (like APIs).
  • Governor Limit: You can make up to 100 callouts per transaction, and each callout can last a maximum of 120 seconds.
  • Why It Matters: If your code depends on external systems, you need to ensure that you stay within the callout limits to avoid errors.
HttpRequest req = new HttpRequest();
req.setEndpoint('https://example.com/api');
HttpResponse res = new Http().send(req);  // 1 callout

6. Future Method Limits

  • Future methods are used to run processes asynchronously (in the background).
  • Governor Limit: You can call 50 future methods in a single transaction.
  • Why It Matters: If you rely heavily on asynchronous processing, keep in mind that you can’t call future methods excessively in one transaction.
@future
public static void processRecords() {
    // Future method logic
}

7. Email Sending Limits

  • Salesforce has limits on how many emails you can send.
  • Governor Limit: You can send a maximum of 5,000 single emails per day.
  • Why It Matters: If you’re sending emails through Apex, you’ll need to keep track of how many emails are sent to avoid exceeding this limit.
Messaging.SingleEmailMessage email = new Messaging.SingleEmailMessage();
email.setSubject('Hello');
email.setPlainTextBody('This is a test email.');
Messaging.sendEmail(new Messaging.SingleEmailMessage[] { email });

8. Concurrent Apex Limits

  • Salesforce limits the number of long-running Apex requests that can execute concurrently.
  • Governor Limit: Up to 10 long-running requests (running longer than 5 seconds) are allowed at a time.
  • Why It Matters: If too many long-running requests are processed at once, Salesforce may delay some requests to avoid performance issues.
// Code that triggers long-running requests
for (Integer i = 0; i < 1000000; i++) {
    // Heavy processing
}

Conclusion

Understanding Governor Limits in Salesforce is crucial because it ensures that the platform remains efficient, fair, and scalable for all users. These limits may seem restrictive, but they encourage you to write optimized and efficient code.

Whether it’s SOQL query limits, DML statements, CPU time, or heap size, each limit helps keep Salesforce running smoothly in its multitenant environment. By being aware of these limits and working within them, you’ll be able to build robust and scalable applications without running into performance issues.

As you start coding in Salesforce, always keep these limits in mind to avoid common pitfalls and ensure your applications run smoothly!

Related Posts

Subscribe
Subscribe