Answering the What & Why of Governor Limits in Salesforce

Rules exist wherever there are finite resources & Salesforce isn’t an exception. In fact, Salesforce Governor limits are one of the important set of regulations that has allowed it to stay as the world’s #1 customer relationship management (CRM) platform. 

These rules stop major companies that offer solutions like Salesforce customization services from over-utilizing Salesforce cloud’s resources. Before you understand what are the rules, let us enlighten you on why these exist.

Why Is There a Need for Salesforce Governor Limits?

Salesforce works in a multitenant structure. This means that each piece of its software runs on a server that caters to multiple users at the same time. 

This is better understood by comparing it to a village well. Everyone uses the water in the well, but if a couple of families overused it, there won’t be enough to go around. Some families will be left with little water, while others might have to deal with getting none at all!

Similarly, the tens & thousands of Salesforce org share all resources on the server. Governor limits ensure no users hog database, memory or processor resources by dictating the limits of what a code can do when executed. 

What are Salesforce Governor Limits?

Governor limits are a set of rules & regulations that cap every individual user’s code to make way for smooth processing. It shuns monopolistic use of the shared resources by restricting Apex implementation & runtime. For instance, on reaching the said limit in any Salesforce integration services, it displays an error & pauses the processes that led to it. 

There are many types of governor limits, and all are associated with one or a combination of factors. While it directly ties some to your Salesforce Edition, others are strictly associated with Apex programming & a few are limits Salesforce can change. Understanding these limits lets developers architect their way around it to offer the best Salesforce customization services & other results they want.

a. Per-transaction Apex Limits

This type of Apex governor limit counts for each Apex transaction. It sets the bar at 50,000 SOQL searches for the maximum number of records. The user can issue a maximum of 20 SOQL queries per transaction & 150 DML statements. They can also use only 100 call-outs per transaction regardless of it is HTTP requests or web service calls. It also differs for synchronous & asynchronous limits:

Synchronous limit- 100 SOQL queries; Overall heap size is equal to or less than 6MB.

Asynchronous limit- 200 SOQL queries; Overall heap size is equal to or less than 12MB.

b. Per-transaction Certified Managed Package Limits

Packages that have cleared the security requirements of AppExchange are called certified managed packages. These packages have unique namespaces & are installed directly into your org from AppExchange. 

Made by certified Salesforce ISV partners, these have their own limits, which are often more than the usual per-transaction limits. For example, certified managed packages have 11 times more SOQL limit, increasing its limit from 100 to 1,100.

c. Lightning Platform Apex Limits

These limits aren’t fixed on Apex Transactions but instead are enforced by the Lightning platform. The users are limited to 2,50,000 asynchronous Apex method executions or no. of user licences (in your org) multiplied by 200, whichever number is greater. The concurrently scheduled Apex classes have a maximum cap of 100 or 5 in the case of the developer edition.

Conclusion

Apart from these, there are static limits, size-specific limits & other miscellaneous limits. The developers that understand these limits & find a way to work with them can provide better Salesforce integration services & similar services than others. 

We at AtoCloud have developers who are well versed in everything related to Salesforce. We offer a wide variety of services to help you make the most out of Salesforce.

Contact us to get in touch with our experts.