Governor Limits in Salesforce

The platform of Salesforce CRM is used by several business enterprises pertaining to all scales of operation and functioning in all industry sectors. For more than two decades now, Salesforce has been serving all the complicated needs arising out of small, medium and large enterprises that involve effective management of customer database.

Salesforce Developers provide an array of services to their clients that are specifically tailored according to their needs. They help in designing, building and customizing several Salesforce tools, platforms and applications according to the needs of the clients.

However, the activity of Salesforce development and operations is not without restrictions and regulations. There are certain specific regulations to be followed by Salesforce Developers while making important changes in the system while using the platform of Salesforce CRM. The majority of these regulations comprise of Governor Limits.

However, in order to understand what these Governor Limits are and how they restrict the activities of Salesforce Developers, it is important to understand the concept of a multitenant architecture.

What is the Multitenant Architecture?

If a single software platform (or any platform in general) is used by multiple users, it is called a multitenant architecture. Salesforce CRM falls under the category of multitenant architecture as all the operators use the same version and the same architecture of the platform.

A key difference between multitenant and single-tenant platforms is the fact that multitenant platforms upgrade themselves on a regular basis and send uniform updates to all their users. Owing to its cloud-based architecture, Salesforce CRM relieves the users of the efforts that go into maintaining hardware and software of the platform. Having a multitenant architecture also ensures that the users will be able to avail of the latest versions of applications installed in their systems.

What Are Governor Limits?

Governor Limits in Salesforce are restrictions imposed by Force.com on the Salesforce Developers regarding the handling of data through code execution on the platform of Salesforce CRM. One of the major reasons behind having Governor Limits is the issue of acquiring resources from other developers.

It is important for developers to follow Governor Limits while using Salesforce owing to the platform being multitenant. Owing to the wide reach of Salesforce and its cloud-based infrastructure, numerous customers and organizations use the same platform. It is essential to follow regulations to avoid unwanted resources being used by the developers. In case any of the Salesforce Governor Limits are not met, an error will be raised and the users will be immediately notified of the same. This error would then result in the shutting down of the program being operated by the user.

Owing to the mechanism of Governor Limits, it is important for every developer to make sure that their code is sufficiently scalable and in no way violates the limits, which are also called Single Trigger Execution.

Types of Governor Limits

Here are all the major Governor Limits in Salesforce, discussed in detail:

Per-transaction Apex Limits

These are the Apex Governor Limits used for the counting of every Apex transaction undertaken by a user. These limits restrict the total number of SOQL queries that can be issued to 100 in case of synchronous limits and 200 in case of asynchronous limits.

The upper limit for the total number of records that can be retrieved using SOQL queries is set to 50,000. Also, a user is allowed to issue a maximum of 20 SOSL queries for any transaction, with not more than 150 DML statements to be issued.

The users are allowed a maximum of 100 callouts in any transaction, be it in the form of HTTP requests or web service calls. Also, the maximum cumulative timeout allotted in a transaction for all callouts is set to 120 seconds. According to these Governor Limits, the total heap size should not exceed 6 MB in case of synchronous limits and 12 MB in case of asynchronous limits.

Per-transaction Certified Managed Package Limits

These are the Governor Limits that take Salesforce Certification into consideration. A certified managed package is a Salesforce managed package that has been successful in passing the security checks regarding AppExchange carried out to determine the majority of transaction limits.

These packages are built by the ISV partners of Salesforce and implemented by installing the same in the client organization systems through AppExchange. These Governing Limits in Salesforce impose no restrictions on the number of certified namespaces a user can access in one single transaction. However, it is also important to note that the user should not exceed the number of operations performed in one namespace than the number mentioned in the per-transaction limits.

Moreover, the users are restricted in using the overall number of operations to be performed in every transaction across the concerned namespace, which is limited to 11 times. Also, the collective limits such as maximum CPU time do not influence the shared limits on the concerned namespaces.

It is important for a developer to note that all the transaction limits are considered on an individual basis for certified managed packages except the total heap size, maximum number of unique namespaces, maximum CPU time and maximum transaction execution time.

These Governor limits in Salesforce are applicable to all transactions carried out by developers and operators, including the certified managed packages running in a common transaction. However, if an AppExchange package created by an uncertified ISV partner is installed in the system, the code belonging to that package will be aloof from its Governor Limits.

Static Apex Limits

These are the Apex Governor Limits pertaining to Static Apex, i.e. involving multiple callouts, loops, queries, batch sizes and records along with the transactions undertaken by the users.

According to these limits, a user is allowed not more than 10 seconds for the default timeout regarding the callouts in one transaction. Users are also required not to exceed 6 MB of the callout response for synchronous Apex (and 12 MB for asynchronous Apex), be it HTTP requests or web service calls.

Static Apex Limits restrict the maximum runtime for a SOQL query to 120 seconds before the transaction is canceled by the platform of Salesforce. The batch size of Apex triggers and for loop lists are both fixed at 200 each. Also, the developers are allowed a maximum of 5000 class and trigger code units while deploying Apex on the platform.

Lightning Platform Apex Limits

These are the Governor Limits managed by the Salesforce Lightning Platform as none of these limits apply to the Apex transactions carried out by developers. According to these limits, users are allowed a maximum of 250,000 (or a total number of user licenses in the company multiplied by 200, whichever is greater) executions pertaining to asynchronous Apex method.

Moreover, the users cannot exceed 10 concurrent transactions that are synchronous in nature for long-running transactions. The maximum number of Alex classes that can be concurrently scheduled is limited to 100 (5 in case of Developer Edition Organisation). Also, there can be a maximum of 50 query cursors that are concurrently open for every user on the platform.

Size-specific Apex Limits

These are the Governor Limits that are designed specifically to ensure the absence of oversized items in triggers, classes and other similar components. According to these limits, users are allowed to have a maximum of 1 million characters in a class as well as a trigger. They are allowed to have a maximum of 6 MB of code that can be used by Apex codes pertaining to org1. Also, the limit of method size 2 for every user is set to 65,535 bytecode instructions compiled together.

Email Limits

Push Notification Limits

The maximum push notifications allowed for each mobile app associated with your Salesforce org depends on the type of app.

Advantages of Governor Limits

Here are some of the major advantages of having Governor Limits restricting the activities of Salesforce Developers:

1. Salesforce Governor Limits stop a foreign organization from executing a lengthy code that can otherwise take up a considerable amount of space in your system’s memory.

2. Apex having totally separate and unique coding limits helps other entities using up more resources than required.

3. The Governor Limits help users in staying in the technically and ethically correct space of Apex coding.

Avoiding Governor Limits

As much as it is important for developers to know all the relevant Governor Limits, it is also important for them to know how to handle Governor Limits in Salesforce. There are certain processes you can follow in order to avoid these limits, some of which are mentioned here:

1. You can choose to not have SOQL queries and DML statements within the FOR loop to avoid certain limits.

2. You can avoid using DML or SOQL operations in a loop pertaining to a transaction.

3. You can bulkify the necessary codes and relevant helper methods.

4. You can choose to query data sets having large volumes.

5. If there is a need for processing more than 50,000 records, you can opt to use Batch Apex to do so.

6. You can choose to streamline different triggers on the same Salesforce object.

7. You can opt for using streamlining queries and collections for transaction loops.