Salesforce Governor Limits

Before starting to know all the rules(which we are always so excited to follow.Not!). We need to know why we need all these rules(which Salesforce makes us follow like a strict Principal).

Don’t forget to check out: Increases in Governor Limits in SFDC Winter 17 Release

As we all know(we kinda have to know because that is all Salesforce is about!), Salesforce is a multi-tenant environment. Multi-tenant environment is an architecture in which a single instance of a software application serves multiple customers. These customers are tenants. Now, to ensure that these tenants don’t get the monopoly of resources, Governor limits are enforced.

Governor limits are runtime limits enforced by Apex runtime engine, that the code runs without any error. Governor limits are Salesforce’s way of forcing to write efficient, scalable code considering best practices.

All good and well, we now understand the need for rules. Now we get to know these limits. There are a number of factors that determine what Governor limit is used, and when it is applied.

Governor limits are applied at-  insert, update, delete, merge, upset and undelete, executing SOQL queries. Governor limits are shared by the organization, from beginning till the end of execution. Any Apex class, method or trigger invoked by code executed within these entry points will count towards the same governor limits as it’s a synchronous request.

Few important Governor Limits in Salesforce :

• SOQL queries per transaction 100(Synchronous), 200(Asynchronous)
• Total no. of records retrieved by SOQL query
• 50,000 Total no. of DML statements issued
• 150 Total no. of records retrieved by a single SOSL query
• 2,000 Total no. of  SOSL queries issued
• 20 Total no. of records retrieved by Database.getQueryLocator10,000 Total no. of callouts(HTTP requests or Web service calls) in a transaction
• 100 Total stack depth for Apex invocation that recursively fires triggers due to DML Statements.

Total no. of records processed as a result of Approval.process, DML statements, or database.empty recycle bin 10,000 Maximum cumulative timeout for all callouts120 seconds maximum no. of Apex jobs added to the queue using System.enqueue Job 50 Maximum no. of methods with future annotation allowed for every Apex invocation 50Total no. of sending email methods allowed

10Maximum execution time for each Apex transaction 10 minutes total heap size 6MBCPU time on the Salesforce servers 10,000 milliseconds

Maximum no. of push notifications that are allowed to send in each push notification method call2,000

Maximum no. of push notification method calls that are allowed per Apex transaction10

There are some ways to ensure that the code won’t hit Governor Limits.

Use collections(like List) so that for every record, there is no need to use a separate DML. Reduce the queries count, also try to fetch the data in the same query than calling Database a number of times. Never ever(this is most important to remember!) write DML or query inside any loop. Use @Future annotation to bypass the Governor limit errors. Do bulky of your code. Use Test.startTest() method in Test class, to get the fresh set of governor limits for the remainder of the test until you call Test.stopTest.