What are Salesforce Governor Limits? 

June 21, 2022

June 22, 2022

Nitin Dangwal

What are Salesforce Governor Limits? 

Salesforce CRM is utilized by an assortment of businesses of all sizes and in different industries. Salesforce has been involved in the effective administration of client data for more than two decades. It has several revolutionary concepts and practices, as well as the ability to access your data anywhere and anytime. This platform has a large number of servers throughout the world, and the organization where you work would also be one of them. These servers have massive databases and machines, and they are so powerful that each server can host many Salesforce instances from different corporations.  

Salesforce Developers offer a variety of services to their customers that are precisely tailored as per their requirements. They help in the design, development, and customization of a variety of Salesforce products, platforms, and apps to meet the demands of their clients. But there always exist rules wherever there are finite resources and Salesforce is not an exception.

Salesforce development and operations are not without constraints and regulations. Salesforce developers must adhere to several guidelines while making significant modifications to the system when using the Salesforce CRM platform. And most of these rules and regulations include Salesforce Governor Limits. 

What is Multitenant Architecture?

To understand the Governor limits in Salesforce and how they limit Salesforce developers' operations, it is first crucial to understand the concept of a multitenant architecture. Multitenancy refers to the method of software operation in which multiple independent instances of one or more programs share a common environment.

Multitenant architecture in more simple words is when a single software platform (or any platform in general) is used by several users. Because all the operators use the same version and design of the platform, therefore the Salesforce CRM falls under the category of multitenant architecture.

Here is an example to help you understand:

Consider Salesforce multitenancy simply like renting an apartment in a building. Electricity, gas, and wi-fi bandwidth are all shared resources for every building in the apartment.

Now if numerous flats start plugging in heavy-duty appliances capable of consuming all the electricity. Think what would happen if other flats began downloading large files from the internet.

Even if you paid a premium, it would be challenging to live in a flat where you could not receive proper electricity or reliable Wi-Fi bandwidth.

Here the flats are separate Salesforce organizations, and the apartment complex is a Salesforce server. And this distribution of shared resources is multi-tenancy architecture. 

There is one more term used i.e., Single-tenant platforms, and the difference between the single and multi-tenant platforms is that the single-tenant requires users to upgrade it regularly.

Multitenant platforms, on the other hand, upgrade themselves regularly and spread uniform updates to all their users. When it comes to Salesforce, it is a cloud-based CRM, so users do not have to worry about maintaining the Salesforce Platform's software and hardware. 

Also, read: What is Salesforce Health Cloud? Its features & Benefits

What are the Salesforce Governor Limits?

Salesforce Governor Limits are commonly referred to as Apex Governor Limits because they are related to apex customizations and modifications.

The apex runtime engine enforces these runtime limitations to develop scalable and efficient code and prevent processes from monopolizing shared resources.

Governor limits in Salesforce are a vital set of rules that made Salesforce the world's most popular and authorized customer relationship management (CRM) platform.

Salesforce Governor Limits, to put it in simple terms, are usage caps imposed by Salesforce to ensure efficient processing. This allows multiple users to access the platform at the same time without slowing it down. 

This is critical since each programming environment has its own set of structures, capabilities, and limitations. All the platform's programs, services, and applications run in a multi-tenant environment, which means that their resources, such as memory, network, and database connections, are shared with every other program on the platform. As a result, the platform must guard against rouge, and apps overwhelming system resources. 

Every developer must ensure that their code is properly scalable and does not violate the limits. So, it is crucial to follow regulations to prevent developers from wasting resources.

If any of the Salesforce Governor Limits are exceeded or are not met, an error will be generated, and users will be notified promptly. The user's program would then be shut down because of this error. 

Also, read: What is Salesforce Enterprise Territory Management?

Types of governor limits in Salesforce

Here is a sheet for Salesforce Governor Limits that summarises the most important limits that everyone should be aware of:

Overview	Governor Limit
The total number of SOSL queries issued in Salesforce	20
DML Governor Limits in Salesforce (Total number of statements issued per transaction)	150
Total number of records retrieved by a single SOSL query	2000
Total number of records retrieved by SOQL queries	50000
Total number of records retrieved by Database.getQueryLocator	10000
Salesforce Governor Limits for heap size total	6 MB/12 MB

The following are the Apex Governor Limits in Salesforce: 

1) Per-Transaction Apex Limits:   

Apex Limits are applied per transaction and are counted for each Apex transaction. These specific limits in the execution method for executing each batch of records will be reset when using Batch Apex. 

The restrictions for the synchronous and asynchronous Apex are summarized in the table below: 

Factor	Synchronous Limit	Asynchronous Limit
Total SOQL queries issued	100	200
Total records retrieved by SOQL queries	50,000
Total records retrieved by Database.getQueryLocator	10,000
Total SOSL queries issued	20
Records retrieved by a single SOSL query	20,000
Toal DML statements issued	150
Total records processed by DML statements	10,000
Stack depth for Apex invocation	16
Total callots in a transaction	100
Methods allowed per Apex invocation	50	0 in batch & future contexts, 1 in queueable context
Number of Apex jobs added	50	1
Toal sendEmail methods allowed	10
Total heap size	6 MB	12 MB
Max. CPU time on Salesforce servers	10,000 milliseconds	60,000 milliseconds
Execution time for Apex transaction	10 minutes
Max. push notifications per Apex transaction	10
Max push notifications send through each push notification method call	2000

2) Per-Transaction Certified Managed Package Limits 

These are the limits that are imposed on managed packages and are different from limits that are applied to the apex that is not part of the managed package.

If a managed package built by a Salesforce ISV has passed a security assessment, the per-transaction limits are often higher. 

Factor	Limit
Total SOQL queries issued	1100
Total retrieved records by Database.getQueryLocator	110000
Number of SOSL queries issued	220
Total DML statements issued	1650
Total Callouts in a transaction	1100
Toal sendEmail methods allowed	110

For certified managed packages, all transaction restrictions apply individually, except: 

• Total heap size 
• Maximum CPU time 
• Maximum transaction execution time 
• Maximum number of unique namespaces 

Also, read: Pipedrive vs Salesforce: Which CRM Is Best for Your Business?

3) Lightning Platform Apex Limits 

These are the Governor Limits set by the Salesforce Lightning Platform. None of these limits apply to Apex transactions executed by developers. 

Description	Limit
The maximum amount of asynchronous method executions per day	25,000
Parallelly scheduled apex classes	100
Queued Apex jobs	5
Max. batches submitted	5
Parallelly opened query cursors/user	50
Parallelly opened query cursors/user	15

4) Static Apex Limits 

These are the apex governor limits set for the static apex, which apply to different types of queries, callouts, records, loops, and batch sizes, as well as different transactions undertaken by the users. 

Description	Limits
The default timeout for transaction callouts	10 seconds
Max. size of callout request or response	6MB (Synchronous) 12 MB (Asynchronous)
SOQL query runtime before cancellation of a transaction	120 seconds
Max. number of class and trigger units of code	5000
Trigger batch size for Apex	200
Size of loop list batch	200
Batch Apex query returned records in Database.QueryLocator	50 million

5) Size-Specific Apex Limits 

These limits are linked to the size and the number of lines of code on the platform. These are primarily utilized to ensure that no oversized items exist in classes, triggers, or the org. 

Description	Limit
The maximum amount of characters/ class	1 mn
The maximum amount of triggers/ class	1 Million
Apex maximum code utilization	6 MB
Limit for method size	65,535

Why are Salesforce Governor Limits enforced?

Salesforce's platform provides customization in the form of Apex trigger, web services, or declarative changes like flows and process builders. When these customizations run on the platform, they consume limited resources that are shared with other Salesforce instances.

Salesforce makes sure that its platform runs smoothly and that its customers are not disturbed by server failures. As a result, Salesforce Governor Limits were put in place and enforced.

They ensure that any Salesforce instance that shares resources with other instances does not consume all the finite resources and that resources are distributed properly according to the instance subscription model. 

Advantages: 

• Salesforce's governor restrictions prohibit other organizations from operating and hence executing lengthy code, which can eat up a lot of memory and even the cloud CPU. 
• Apex has an entirely separate set of coding limits. 
• These governor limits keep us in the right space of coding when working with Apex. 

Also, read: Salesforce Edition Comparison: Features and Applications

How can you avoid hitting these Salesforce Governor Limits?

It is our responsibility to make sure that our code is scalable and does not exceed the governor's limits. Several tricks and tips can be used to ensure that any customization code is written within these Salesforce Governor Limits. For this you must follow these steps: 

• In FOR loop, make sure there are no DML statements or SOQL queries. 
• In the loop, avoid using SOQL or DML operations. 
• Set Governor Limits, Check the 'Send Apex Warning Emails' option on your user record to receive email warnings. 
• Bulk up your code and helper methods. 
• Large data sets can be queried. 
• To avoid apex heap size problems, make sure variables are private or transitory unless they need to be accessible outside the class. 
• If we need to process 50,000 records, you should use Batch Apex. 
• Streamline the execution of several triggers on a single object. 
• For loops, use streamlined queries and collections. 

Also, read: Salesforce Customer 360 – All you need to know about

Conclusion

As you can see, there are different kinds of governor limits available in Salesforce, and this is for a good reason: they help us become more efficient administrators and developers. There are several general patterns you can adopt to make sure that you stay within these limits. In general, the most well-known limits in a single transaction revolve around SOQL and DML limits. 

Developers will automatically write optimized code that delivers the optimum performance when customizations are done while keeping these limits in mind. Hopefully, you must have now understood that getting past governor limits can be both challenging and enjoyable. If you have any further questions or require help from professionals, feel free to reach us. 

[sc name="Salesforce Automation"] [add_newsletter] [add_related_page_diff_contents blog_cat = "salesforce"]