I assume many of us have at least once encountered this type of error or a similar one: ‘DeleteCaseTrigger: System. LimitException: Too many query rows: 50001’. This error means that you have just hit the Salesforce Governor limits in your Salesforce org. These limits are key to Salesforce development, ensuring the platform stays efficient and reliable even with many users accessing it at once. But what exactly are Governor Limits, and why are they so important?
Governor Limits are rules set by Salesforce to keep shared resources in the multi-tenant environment healthy. Since Salesforce uses a shared infrastructure where multiple organizations (tenants) use the same instance, these limits prevent any single tenant from hogging resources. This ensures fair resource distribution, optimal performance, and system integrity.
Understanding and respecting these limits is crucial for developers. Ignoring them can lead to failed transactions and poor performance, ultimately affecting the user experience. In essence, Governor Limits are Salesforce's way of enforcing best practices and encouraging developers to write efficient, scalable code.
Governor Limits may seem restrictive at first, but they play a vital role in maintaining a balanced and high-performing ecosystem and different implementations, such as Salesforce Commerce Cloud implementation. In the following sections, we'll explore what these limits involve, the challenges they present, and how developers can effectively manage and work within them.
Insight:
You can encounter the limit error not only when compiling your code but also in other automation, such as Salesforce Flow.
To effectively handle Governor Limits in Salesforce, it's important to understand what they are and the various types that exist. AppExchange consultants are professionals who can assist in managing these limits efficiently. In this section, I’ll try to explain Governor Limits and categorize them to help you understand their scope and application.
Types of Governor Limits
Apex Execution Limits
Apex execution limits ensure that no single process consumes too many resources, protecting the overall system performance. These limits include:
SOQL Queries: Apex limits the number of SOQL queries that can be executed in a single transaction to 100 for synchronous transactions and 200 for asynchronous transactions. For example, if an Apex class tries to execute 101 SOQL queries in a synchronous transaction, it will fail.
CPU Time: The maximum amount of CPU time allocated for an Apex transaction is 10,000 milliseconds for synchronous transactions and 60,000 milliseconds for asynchronous ones. This prevents any single transaction from overloading the server.
DML Operations Limits
These limits control the number of data manipulation language (DML) operations that can be performed within a single transaction:
DML Statements: The limit for DML statements (insert, update, delete, etc.) is 150 per transaction. This means that if a process tries to perform 151 DML operations, it will be stopped, and an error will be thrown.
Records Processed: A single transaction can process up to 10,000 records via DML operations. This ensures that large data operations do not hinder system performance.
Callout Limits
Apex limits the number and duration of external web service callouts to ensure balanced usage:
Number of Callouts: Each transaction can include up to 100 callouts (HTTP requests or web service calls). This helps maintain the availability of external services.
Callout Time: The cumulative timeout for all callouts in a transaction is 120 seconds. This prevents long-running callouts from blocking system resources.
Heap Size Limits
The heap size limit governs the amount of memory allocated to an Apex transaction:
Heap Size: The heap size limit is 6 MB for synchronous transactions and 12 MB for asynchronous transactions. This helps control the memory usage of complex or large-scale processes.
Email Limits
Salesforce controls the number of emails that can be sent to prevent misuse:
Single Email Messaging: The limit for single email messages is 10 per transaction, ensuring that email services are not overloaded.
Mass Email Messaging: Limits also exist on the number of mass emails that can be sent, managing server load and preventing spam.
API Limits
These limits ensure fair usage of the Salesforce API:
API Calls: Each Salesforce org has a daily limit on the number of API calls it can make. This prevents any single org from overloading the system.
Concurrent API Calls: There are also limits on the number of concurrent API requests, which helps to prevent server overload.
Platform Event and Streaming API Limits
These limits control the usage of platform events and streaming APIs:
Event Delivery: There is a cap on the number of platform events that can be delivered in a transaction, ensuring that the event processing system is not overwhelmed.
Streaming API: Limits exist on the number of push topics and the number of clients that can be connected simultaneously to the Streaming API, maintaining balanced system performance.
Storage Limits
Salesforce imposes limits on both data and file storage to manage resources effectively:
Data Storage: Each org has a limit on the amount of data that can be stored, which varies by Salesforce edition. This ensures that storage resources are used efficiently.
File Storage: Similarly, there are limits on the amount of file storage available, including attachments and documents.
Why Understanding These Limits Matters
Knowing and understanding these various Governor Limits is crucial for Salesforce developers. It allows them to design applications that are efficient and comply with Salesforce's resource management policies. By adhering to these limits, developers can avoid runtime exceptions and performance issues, ultimately providing a smoother user experience.
Wrapping Up
Navigating Salesforce's Governor Limits is important for building efficient and reliable applications on the platform. Understanding the different types of Governor Limits — such as SOQL query limits, DML operation limits, CPU time limits, heap size limits, and API call limits — is essential.
These limits help keep the system running smoothly by preventing any one user or application from hogging resources. Although these limits can seem restrictive, they are designed to ensure fair resource distribution and maintain system performance.