5 Ways to Overcome Governor Limits in Salesforce
Software-as-a-Service (SaaS) providers face unique challenges in providing cloud-based storage and computational power on demand and functionally limitless scalability. To keep these ease-of-use services running with unpredictable demand, providers sometimes have to impose limits on the demands platform code can execute. Governor limits in Salesforce are an example of such code restraints.
In this guide, you’ll learn what governor limits in Salesforce are and how Apex developers can write code that avoids hitting their org’s limits.
What Is Multitenancy in Salesforce?
To understand Salesforce governor limits, it helps to begin with an understanding of how cloud-based Software-as-a-Service (SaaS) platforms create real-time scalability for multiple users. The Salesforce platform employs a client service architecture called multitenancy. Multitenant software structures serve all clients simultaneously with resources such as database space, network capacity, and CPU cycles.
Thinking of an apartment building with multiple units and tenants provides an illustrative analogy. In the building, different units share resources such as electricity, gas, water, and internet service. These resources are available on demand at fixed-rate pricing. Turn a switch, and the light comes on. Open the faucet, and water runs. Instant, on-demand availability suits everyone as no one knows exactly how much of any particular resource they need or when they’ll need it.
Now imagine that the tenants in one unit decide to mine cryptocurrency and begin to consume 100 times the average amount of electricity. In another unit, the tenants decide to run the water 24 hours a day to bottle and sell it. Others download large HD videos constantly on dozens of devices. Naturally, the resource-sharing structure ceases to work, both for the tenants and the service provider.
Multitenant SaaS platforms face the same challenges in providing resources to clients. In the analogy, the building is Salesforce, the utilities are computational and storage resources, and the units and their tenants are the individual orgs deployed by users. To prevent scenarios like those illustrated in the analogy, Salesforce employs resource limits – called governor limits – that constrain what your code can perform on the platform.
What Are Governor Limits in Salesforce?
Governor limits are CPU processing use-caps that prevent the code run by individual orgs from hoarding CPU cycles and cutting off other tenant orgs from the platform. They ensure all users receive the same performance standards at all times.
Salesforce uses three different kinds of governor limits.
Salesforce Edition Limits
Some governor limits depend on the Salesforce edition you use and determine the number of custom objects your code can contain.
Other governor limits – known as soft limits – are simply paywalls. These include MB limits for Apex code on a single org. You can purchase greater capacity for a fixed rate. Other soft limits like API and customer data storage depend on the number of Salesforce licenses your org holds and will rise as you acquire new licenses.
Hard limits refer to Apex programming constraints. Hard limits typically involve caps on the maximum number of synchronous qualifiers a script or a query can execute. For example, Salesforce limits the total number of SOQL queries issued synchronously to 100 or the number of SELECT statements in a single transaction to 100.
Hard limits do not vary by edition, and you cannot increase them by purchase. Developers can only overcome these limits by applying Apex-specific approaches to certain query and transaction types. There are six hard governor limit types in Apex programming.
- Per Transaction Apex Limits
- Per Transaction Certified Managed Package Limits
- Lightning Platform Apex Limit
- Static Apex Limit
- Size-Specific Apex Limit
- Miscellaneous Apex Limit
5 Ways to Overcome Hard Governor Limits in Salesforce
Apex developers can use certain workarounds and platform-specific best practices to avoid hitting hard governor limits in their code. Here’s a list of five tips to try.
1. Single Trigger Objects
Apex objects require only one Trigger. If you write multiple Triggers for the same object, you can’t predict their execution order and may hit the per transaction limit on executable commands.
2. Write Trigger Logic in Your Apex Classes
In Apex, run tests can’t see methods written inside Triggers, and their logic can’t be exposed to other objects. The standard Apex best practice for writing Trigger Logic – for testing-in-production purposes and avoiding governor limits – is to write it in the Apex Class known as a Trigger Handler.
3. Context-Specific Handler Methods
You should write separate handler methods for each context if you have a Trigger with multiple context conditions such as IF before and after. This allows other developers to read your code more easily and eliminate it as a possible cause in the case of a tripped limit.
4. Use Collections and Limit FOR Loops in Your Code
FOR loops – especially when they include SOQL and DML – can bloat your code size and push synchronous transactions beyond the limit. To avoid the problems, omit SOQL and DML from your FOR loops and write Collections for multiple records to limit transactions.
5. SOQL Query FOR Loops for Large Data Sets
Individual SOQL queries cannot exceed 50,000 total records. If you have to query a data set that hits your heap limit, write the query inside a FOR loop so that the data set passes in multiple batches using discrete internal calls to query() and queryMore().
Salesforce Application Development with Rainmaker
Rainmaker’s team of experts specializes in Salesforce managed services and custom, feature-rich Salesforce application development. Across your organization, Rainmaker can deliver the Salesforce functionality you need.
To schedule an initial consultation and learn more, contact Rainmaker today.