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 customising 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. 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 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 in maintaining hardware and software of the platform. Having a multitenant architecture also ensures that the users will be able to avail 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 organisations 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 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 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 majority of transaction limits.
These packages are built by the ISV partners of Salesforce and implemented by installing the same in the client organisation 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 allows not more than 10 seconds for the default timeout regarding the callouts in one transactions. 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 an SOQL query to 120 seconds before the transaction is cancelled 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.
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.
Lightning Platform Apex Limits
These are the Governor Limits managed by 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 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.
Advantages of Governor Limits
Here are some of the major advantages of having Governor Limits restricting the activities of Salesforce Developers:
- Salesforce Governor Limits stop a foreign organisation from executing a lengthy code which can otherwise take up a considerable amount of space in your system’s memory.
- Apex having totally separate and unique coding limits helps other entities using up more resources than required.
- 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:
- You can choose to not have SOQL queries and DML statements within FOR loop to avoid certain limits.
- You can avoid using DML or SOQL operations in a loop pertaining to a transaction.
- You can bulkify necessary codes and relevant helper methods.
- You can choose to query data sets having large volume.
- If there is a need for processing more than 50,000 records, you can opt to use Batch Apex to do so.
- You can choose to streamline different triggers on the same Salesforce object.
- You can opt for using streamlining queries and collections for transaction loops.
“Chitiz Agarwal also known as “Kumar” is a Salesforce.com evangelist and architect who has more than 13 yrs of IT experience. He has worked with big MNCs like Accenture and IBM and now running Techila Global Services from last 7 yrs and grown the company to size of 150+. He has delivered more than 700 projects on Salesforce.com till date and participated from initial requirement understanding to final delivery. His twitter handle is @ChitizAgarwal”