Introduction

We use triggers when we can’t complete our functionality with the declarative tools. Triggers allow us to perform some actions before or after any event or changes that occur in Salesforce. It gives us great power in customization but, when not used correctly, can make situations worse. Sometimes developers write Trigger in such a way that makes them difficult to debug the error.

How to simplify the most complex triggers

1. Try to avoid writing complex logic or code in triggers, making code reusable and easy to test. Instead, write complex code or logic in a separate apex class.
2. Write a single trigger for each object to avoid unwanted behavior or conflicts as code gets complex for developers to debug as they have to be aware of all the triggers on that object if we write multiple triggers on the same object.
3. Avoid writing DML statements and SOQL queries in for loop as doing so will throw us with exceptions like SOQL 101 or DML 151.

Using a Flowchart tool

We can make use of any flowchart tool (e.g. Gliffy, Lucid Chart) to divide our problem into smaller pieces. We can make a complete flow chart of our trigger with different nodes through which our problem gets easy for us to solve. This helps us to analyze our triggers in a step-by-step manner, a better and more efficient way.

Using “One Trigger per Object” Design Pattern

The reason behind using ‘One Trigger per Object’ is that there is no order of execution of triggers on the same object. So, it would create problems if we write multiple triggers on the same object. Writing only one trigger gives the power to the developer to control the flow of functionality or logic while calling the execution in other classes.

Using “Logic-less Triggers”

Instead of writing all the code or logic in a trigger, we should write our logic in a separate Apex class called Trigger Handler Class, which would contain multiple methods according to the requirements and call the methods from the handler class into the Apex trigger. This would make the debugging process easy for developers. Developers should try to write less code in the trigger as it will make our trigger code more reusable and manageable as well. It allows us greater flexibility and to write and maintain test classes very easily.

Example

trigger ContactT on Contact (before insert, after insert, before update, after update) {
if(Trigger.isBefore && (Trigger.isInsert || Trigger.isUpdate)){
ContactHandlerClass.recordInsertion(Trigger.new);
}
}

In the above snippet, we have a trigger ‘ContactT’ on the Contact object. Here, we are calling the ‘recordInsertion’ method from a handler class ‘ContactHandlerClass’ for before trigger and Insert or Update context variables.

By Avoiding “Avoid Recursive Trigger”

A recursive Trigger is a trigger that calls itself repeatedly and forms an infinite loop. To avoid the recursive triggers, we make use of a static Boolean variable and check the value of the variable before anything gets executed in the trigger. Set the value of this variable as true initially, make a check, and then set it false once execution is completed.

Below is our Handler Class:

public class AccountHandlerClass{
public static Boolean isExecuted = true;
}
Here, we have the Trigger code.
trigger AccountT on Account(before insert){
if(AccountHandlerClass.isExecuted){
AccountHandlerClass.isExecuted = false;
//code...
}
}