Governor Limits in Salesforce; Meaning, Types and How to Handle Them
What is governor limits in Salesforce?
In this post, we will look at the meaning and types of governor limits in salesforce. Here we will also show you how to handle governor limits in salesforce.
Salesforce is a customer relationship management (CRM) solution that brings companies and customers together. Customer Relationship Management, CRM, is a software that tracks every interaction between current and future customers. It allows businesses to manage relationships and data associated with them. The Salesforce software is that integrated platform that gives all your companies i.e. Marketing, sales, commerce, service etc. a single shared view of every customer.
On Salesforce.com’s CRM functionality, exists a development platform that allows developers to access Salesforce.com’s back-end database and client-server interface to build third-party Software as a Service (SaaS) applications. This platform, Apex, is a proprietary language that allows the execution of flow and transaction control statements on Salesforce.com’s platform server. A transaction is a set of activities that can be executed as a single unit; could either be a class or a trigger.
Read Also: PayPal Business Loan Review; How it Work, Eligibility, Benefits, Interest Rates, How to Apply
What is Governor Limits in Salesforce?
Table of Contents
The Salesforce platform is a multitenant environment i.e. the same resources, infrastructure and version of the platform are shared by all of its users. Considering that Apex runs on such a multitenant environment, there are limits that are strictly enforced to ensure that codes and processes do not over-utilize or monopolize the shared resources. Governor limits in salesforce admin are predefined and if per chance, a code exceeds the execution limits, a runtime exception that cannot be handled is issued.
Types of governor limits in salesforce
The various types of these salesforce API governor limits include,
- Per-Transaction Apex limits
- Per-Transaction Certified Managed Packages Limits
- Lightning Platform Apex Limits
- Static Apex Limits
- Size-specific Apex Limits
- Miscellaneous Apex Limits
Others include Push Notification limits and Email limits.
Per-Transaction Apex limits
This is an example of a salesforce callout limits. These limits count for each Apex transaction. The maximum number of Salesforce Object Query Language (SOQL) queries that can be executed per transaction is 100. The maximum number of records in a deal on which Data Manipulation Language (DML) operations can be performed is 10,000. A maximum number of DML operations per transaction is 150. These are the most common limits encountered by developers when using Salesforce.
Per-Transaction Certified Managed Packages limits
These are per-transaction limits for certified managed packages developed by Salesforce ISV partners installed from AppExchange with unique namespaces. This is an example of a limit class in salesforce. There is no limit on the number of certified namespaces that can be invoked in a single transaction.
However, the number of operations executed in each namespace must not exceed the Per-Transaction limit. The cumulative limit 9n operations that can be executed across namespaces in a transaction is 11 times the per-namespace limit. So if a per-namespace limit for SOQL query is 100,a single transaction can execute up to 1,100 SOQL queries
The cumulative limit does not affect limits shared across namespaces such as the limit on maximum CPU time, total heap size, maximum transaction execution time and a maximum number of unique namespaces. All these exceptions count for the entire transaction and do not affect how many certified packages are running in the same transaction.
Read Also: How to Find Passport Book Number US, Brazil, India, Mexico, Canada, UK
Lightning Platform Apex Limits
These are not specific to an Apex transaction and are enforced by the lightning platform. This limit is for the entire organization and applies to all tests running asynchronously. It is shared with all asynchronous Apex: Batch, Queueable and scheduled Apex and future methods.
Email limits
There are inbound email limits and also outbound email limits. For inbound email, there are limits for the maximum number of email messages processed, the maximum size of an email message, maximum email attachments size etc. The maximum size of email messages for Email Services varies depending on language and character set.
For outbound email, limits exist for both single and mass emails sent using Apex.
Push Notification limits
The maximum push notifications allowed for each mobile app associated with your Salesforce org depends on the type of app. Only deliverable notifications count toward this limit. Each test push notification that is generated through the Test Push Notification page is limited to a single recipient. Test push notifications count toward an application’s daily push notification limit.
For further information on these limits and other types, visit https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm
How to handle governor limits in Salesforce
As developers, it is important to make sure codes written are scalable and do not hit the governor limits. Here are some practices to avoid hitting these limits when writing codes.
- Bulkify your code.
This simply means when combining repetitive tasks in Apex. It is the most important way to avoid hitting the governor limits. Just ensure your code properly handles more than one record at a time.
- Avoid writing DML statements and SOQL Queries in FOR loop.
Placing queries or DML statements in a FOR loop is a mistake that is very common. There is a governor limit that enforces a maximum number of SOQL queries; there is another that enforces the maximum number DML statements. When these are placed in a FOR loop, it makes them reach the limits when databases operations are invoked once per iteration of the loop.
To avoid these, move any database operations out of FOR loop. If querying is required, do it once. Retrieve all necessary data in that single query and iterate over the results. If modification is needed, batch up data in a list and invoke your DML in that list of data.
- Bulkify your Helper Methods.
Ensure that any code running a query or DML operation does it in a bulk manner and is not executed within a FOR loop. Executing queries or DML statements within an iteration adds risks that the governor limits will be exceeded. This is also true for any helper methods an Apex request executes.
- Avoid Process Builder
The Process Builder tool is a very good declarative tool for organizations that do not carry out Advanced Apex. It is not nullified so it does not scale well.
- Try Caching
You could use static variables when you know the data is unlikely to change if and/or when or you could try using platform cache.
- Streamline multiple triggers on the same object.
- Query large Data sets.
- Use the Limits Apex Methods to avoid hitting the governor limits.
- Use @Future appropriately (it helps bypass the governor limits errors).
For more information on handling Governor limits, visit https://developer.salesforce.com/page/Apex_Code_Best_Practices