Salesforce Apex Trigger Best Practices

Introduction

A trigger is an apex component that gets executed automatically when a DML operation is fired on any object. We have some declarative tools for automation, like, Workflow rules, Process Builder, and Flows. In the same way, we have Triggers which is a programmatic approach for automation.

Now, while writing Triggers, we should follow some of the best practices in Salesforce.

Salesforce Apex Trigger Best Practices

Salesforce has provided us Governor Limits to avoid exceeding the usage of resources. So, while writing Trigger, we need to follow some best practices to avoid hitting governor limits. Some are mentioned below:

Using Only One Trigger per Object

Every developer follows this most important practice while writing Trigger; Use only one Trigger per object. This is because there is no order of execution of Triggers in Salesforce. Suppose we have written multiple Triggers on a single object, then we don’t know which trigger will fire according to the event. So, it is recommended to use only one Trigger for every object.

Logic-less Triggers

We should avoid writing logic in Triggers as if we do so, it will be very difficult to maintain and test the code. Also, Readability will be reduced. Instead, we should create a separate class and write our logic in that class method which can be called from Triggers.

Bulkification

When our Trigger works for multiple records in the same way as it works for a single record, then we say that our Trigger is bulkified.

Our Trigger can be bulkified when we avoid writing SOQL and DML statements in for loop. The reason is we have been provided with the Governor Limits in Salesforce. We have a Governor Limit of 100 SOQL queries and 150 DML statements per transaction synchronously.

So, if we use SOQL or DML in for loop, Limits can be exceeded, and there are high chances of hitting Governor Limits which will throw us an exception of SOQL 101 and DML 151.

Implementing SOQL Query FOR Loop

One of the Governor Limits within Salesforce is the Heap Size limit. Heap size is the amount of memory allocated to our objects that are defined in the Apex code. So, to manage heap size, we can use SOQL Query For Loop. This is a runtime Governor Limit. We use SOQL For loop when we need not to create any collection variable to store data as that data will not be used anywhere in the program but in for loop and can directly iterate over the returned set of records given by the SOQL query.

Example:

Instead of writing this way:

List accList = [SELECT Id, Name FROM Account LIMIT 20];
for(Account account : accList){
//code…..
}
Write this way:
for(Account account : [SELECT Id, Name FROM Account LIMIT 20]){
//code…
}

The above syntax will save our heap size and can prevent exceeding the heap size limit of 6MB synchronously and 12MB asynchronously.

Proper Implementation of Future method

It is important to write Apex code in a way so that it efficiently handles bulk records at a time. This is also the case with Asynchronous Apex methods for those who are annotated with the @future keyword.

Avoiding Hard-coding IDs

We should make use of the custom labels or custom settings instead of hardcoding any values like Ids in Apex code to store such hardcoded values.

Avoiding Recursive Trigger

A recursive Trigger is a trigger that calls itself repeatedly and leads to an infinite loop. To avoid this, we need to

1. Create another class called RecursiveTriggerHandler.

2. Make use of a Boolean static variable.

Consider Process Builder and Flows before writing Trigger

Salesforce always recommends using Declarative tools like Process Builder or Flows wherever tasks can be completed using them. But when things can’t be done using declarative tools, we should only go for the programmatical approach or Triggers, in this case.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.