Why do we need Salesforce Trigger Handler Framework ?

If you’re new to Salesforce development, you might have heard about Apex triggers, which are powerful tools that let us run custom code when certain actions happen on Salesforce records. However, as projects grow, handling these triggers efficiently becomes critical. That’s where the Salesforce Trigger Handler Framework comes in. Think of it as a structured way to organize and manage your trigger code so it stays clean, organized, and easy to maintain. Let’s walk through what this framework is, why it’s helpful, and how you can implement it, even as a beginner.

---

Why Do We Need a Trigger Handler Framework?

In Salesforce, Apex triggers can help automate actions whenever data is created, updated, or deleted. For example, let’s say every time a new Account is added, you want Salesforce to also update related Contacts. This sounds simple, but what if we have multiple conditions and actions? Over time, the trigger code can become complex and hard to manage.

The Trigger Handler Framework addresses these challenges by organizing the code into manageable parts. Instead of putting everything into one trigger, this framework lets you separate the logic into different sections, making it easier to read, test, and update later.

Benefits of Using a Trigger Handler Framework

Here’s why adopting this framework is worth it:

• Organized Code: By separating code into parts, you make it much easier to understand and modify.
• Reusable Code: Common actions can be reused in different triggers, so you don’t have to repeat yourself.
• Better Performance: Efficiently organized code can handle bulk records, which is important in Salesforce.
• Easier Testing: By isolating the logic, you can test each part individually, which makes troubleshooting a breeze.

---

Key Parts of the Trigger Handler Framework

Let’s break down the main components of this framework to make it clearer.

1. Single Trigger Per Object

A best practice is to have just one trigger per object (e.g., one for Account, one for Contact). This single trigger is in charge of calling other parts of the framework, keeping it lightweight and organized.

2. Trigger Handler Class

Instead of putting all the logic in the trigger, we create a handler class to hold the actual actions (or “business logic”) we want to perform. This makes the code modular, meaning each piece is self-contained and does one specific thing.

3. Helper Classes (Optional)

Sometimes we need to perform the same task in different triggers, like updating related records. Instead of rewriting the same code, we can put these common actions into a helper class. Helper classes allow us to reuse code without duplicating it.

---

Step-by-Step Guide to Implementing the Trigger Handler Framework

Now, let’s put this framework into action! We’ll go through each step in a simple example for the Account object, where we might want to handle changes to Account records.

Step 1: Create a Trigger

First, we’ll create a single trigger for the Account object. This trigger only “delegates” work to the handler class, meaning it hands off the job to the handler rather than doing the work itself.

trigger AccountTrigger on Account (before insert, before update, after insert, after update) {
    // Creating an instance of the handler class
    AccountTriggerHandler handler = new AccountTriggerHandler();

    // Running the handler’s methods based on trigger events
    handler.run();
}

In this setup:

• We create an instance of AccountTriggerHandler (a class we’ll build next).
• We call the handler’s run method, which will decide what to do based on the type of trigger (insert, update, etc.).

Step 2: Create the Trigger Handler Class

Next, we build the AccountTriggerHandler class. This class contains the actual logic we want to execute. Instead of putting all the code directly into the trigger, we break it into small methods here.

public with sharing class AccountTriggerHandler {

    // This method checks the type of trigger event and calls the right method
    public void run() {
        if (Trigger.isBefore) {
            if (Trigger.isInsert) {
                beforeInsert(Trigger.new);
            } else if (Trigger.isUpdate) {
                beforeUpdate(Trigger.new, Trigger.oldMap);
            }
        } else if (Trigger.isAfter) {
            if (Trigger.isInsert) {
                afterInsert(Trigger.new);
            } else if (Trigger.isUpdate) {
                afterUpdate(Trigger.new, Trigger.oldMap);
            }
        }
    }

    // Method to handle 'before insert' logic
    private void beforeInsert(List<Account> newRecords) {
        // Add logic here, e.g., validation or updating other records
    }

    // Method to handle 'before update' logic
    private void beforeUpdate(List<Account> newRecords, Map<Id, Account> oldMap) {
        // Add logic for before update, such as checking for changes
    }

    // Method to handle 'after insert' logic
    private void afterInsert(List<Account> newRecords) {
        // Add logic here, e.g., notifying users or creating related records
    }

    // Method to handle 'after update' logic
    private void afterUpdate(List<Account> newRecords, Map<Id, Account> oldMap) {
        // Add logic for after update if needed
    }
}

What’s happening here?

• The run method checks if the trigger event is before insert, before update, after insert, or after update, then calls the appropriate method.
• Each method (beforeInsert, beforeUpdate, etc.) handles a specific type of trigger event. This way, all logic is cleanly separated.

Step 3: Create a Helper Class (Optional)

If you have actions that need to be performed across multiple triggers or objects, it’s best to put them in a helper class. This way, you only write the code once and can use it anywhere.

public with sharing class AccountHelper {

    public static void updateRelatedContacts(List<Account> accounts) {
        // Logic to update Contacts related to the given Accounts
    }
}

Then, inside the AccountTriggerHandler, you can call this helper method whenever needed, like this:

private void beforeInsert(List<Account> newRecords) {
    AccountHelper.updateRelatedContacts(newRecords);
}

---

Best Practices for Using the Trigger Handler Framework

Here are a few tips to get the most out of this framework:

1. Bulkify Your Code

Salesforce often processes multiple records at once, so always write your code to handle bulk records. Avoid single record processing, and instead, use lists (like List<Account> in our example) to manage multiple records efficiently.

2. Avoid SOQL or DML in Loops

Salesforce has strict limits on database operations. If you use SOQL (Salesforce Object Query Language) or DML (Data Manipulation Language) inside a loop, you can quickly hit these limits. Instead, gather all records in a list and perform the query or update outside the loop.

3. Use Trigger Context Variables

Salesforce provides context variables like Trigger.new, Trigger.old, and others, which hold records being processed by the trigger. This lets you access and manipulate data in bulk without making additional database calls.

---

Wrapping Up: Why Use the Trigger Handler Framework?

The Trigger Handler Framework is like a “blueprint” that helps keep your Salesforce triggers organized, making it easier to manage complex projects as they grow. By keeping your code modular and organized, you:

• Make your code cleaner and easier to understand.
• Avoid the hassle of rewriting the same logic in multiple places.
• Write code that’s easier to test, troubleshoot, and optimize.

With this framework, you’ll be better equipped to handle any changes or additions in the future without risking breaking other parts of the system. Adopting this approach early in your Salesforce development journey will set you up for long-term success. Happy coding!