Limits and Best Practices of Apex Triggers

Limits and Best Practices of Apex Triggers

Are you wondering how to create smart and robust web or mobile applications and how to integrate them with Salesforce in a seamless manner? Salesforce, the world’s #1 CRM, provides one of the most powerful Force.com programming languages known as Apex. 

Apex is an object-oriented programming language that allows you to develop custom business logic on the platform by writing Apex triggers, custom VisualForce Controllers and extensions, Anonymous Apex codes, etc. Salesforce.com imposes a set of rules and limits for writing Apex code in Salesforce to ensure the efficient use of resources in the Salesforce environment.Before we delve into the best practices for writing Apex code, let’s have a quick overview of the Apex trigger. Apex triggers enable you to perform custom actions before or after changes to Salesforce records like insertions, updations, or deletions. A trigger in Apex code is a set of statement that executes before or after the following types of operations, such as insert, update, delete, merge, upsert, and undelete.

Types of Triggers in APEX

Apex provides two types of triggers based on the time of execution:

Before Triggers: These triggers execute before the records are inserted, updated, deleted, or undeleted in any object. Put simply, these triggers are used to update or validate record values before they are saved to the database.

After Triggers: These triggers execute right after the records are inserted, updated, deleted, or undeleted in any object, and before the commit is called. They are used to retrieve field values that are created by the system, such as CreatedBy, LastModifiedBy, RecordID, etc.

Best practices to write and design Apex Code in Salesforce

  • Write code with collections, you don’t need to write a separate query or separate DML for each and every record.
  • Reduce the count of queries and try to fetch all needed data in the same query rather than calling them again and again to the database.
  • Never write DML or query in any loop.
  • Use @Future annotation to bypass Governor Limit errors.
  • Use Collection List and Map to avoid DML and SOQL inside for Loop.
  • Always query large data set with the maximum possible filter to avoid Governor Limits.
  • Use Limits Apex Methods to avoid hitting Governor Limits in Salesforce.

Governor Limits in Salesforce

  • In one transaction, you can use a maximum of 100 SOQL queries.
  • In one transaction, you can use a maximum of 20 SOSL queries.
  • In one transaction, you can use a maximum of 150 DML statements.
  • In one transaction, you can fetch a maximum of 50k records in SOQL.
  • In one transaction, you can fetch a maximum of 2k records in SOSL.

Final Words

The above-stated best practices will definitely help make your code more manageable, dynamic, reusable, and readable. By following these best practices in your code, you can avoid breaking the governor limits of the Salesforce Platform and improve your application’s performance.Want to know more about Salesforce Governor Limits? Simply contact our Salesforce certified consultants now. Our Salesforce certified experts will guide you on how to write effectively versatile code without hitting governor limits imposed by Salesforce.

Leave a Reply