In small orgs, developers often write logic directly inside triggers.

Over time this leads to:

● Unmaintainable code
● Recursion bugs
● Governor limit failures
● Difficult debugging
● Tight coupling

Enterprise orgs solve this by using a Trigger Framework.

→ A trigger becomes a router.
→ Logic lives in handler classes.

In this project, we will build a reusable Trigger Framework for the Account object.

Business Requirement

Create a scalable trigger architecture that:

● Supports all trigger events
● Prevents recursion
● Keeps logic separated
● Allows easy future expansion

We will implement a sample rule:

● When Account is created → Auto-populate Description
● When Account is updated → Log change

Data Model (Objects / Fields)

Object Used:
● Account

Fields Used:
● Description

Functional Flow (How It Works)

1. Salesforce fires Account trigger.

2. Trigger routes execution to handler.

3. Handler identifies event context.

4. Business logic executes.

5. Recursion is prevented.

6. Transaction completes safely.

Apex Design (What We Are Building)

Architecture layers:

● Trigger
● Base Trigger Handler
● Object-specific Handler
● Business Logic

Design principles:

● Single Responsibility
● Bulk safe
● Extendable
● Testable

Important Best Practice

Salesforce recommends:

Only ONE trigger per object.

If your org already has an Account trigger, merge your logic into the same framework trigger instead of creating multiple triggers.

Multiple triggers can cause unpredictable behavior.

Implementation Steps

◆ Step 1 – Create Base Trigger Handler

Open Developer Console.

File → New → Apex Class

Class Name:

TriggerHandler

Paste And Save:

public abstract class TriggerHandler {

    private static Set<String> executedHandlers = new Set<String>();

    public void run() {

        String handlerName = String.valueOf(this);

        if (executedHandlers.contains(handlerName)) {
            return; // Prevent recursion
        }

        executedHandlers.add(handlerName);

        if (Trigger.isBefore) {
            if (Trigger.isInsert) beforeInsert();
            if (Trigger.isUpdate) beforeUpdate();
        }

        if (Trigger.isAfter) {
            if (Trigger.isInsert) afterInsert();
            if (Trigger.isUpdate) afterUpdate();
        }
    }

    protected virtual void beforeInsert() {}
    protected virtual void beforeUpdate() {}
    protected virtual void afterInsert() {}
    protected virtual void afterUpdate() {}
}

◆ Step 2 – Create Account Trigger Handler

File → New → Apex Class

Class Name:

AccountTriggerHandler

Paste And Save:

public class AccountTriggerHandler extends TriggerHandler {

    protected override void beforeInsert() {
        for (Account acc : (List<Account>) Trigger.new) {
            acc.Description = 'Created via Trigger Framework';
        }
    }

    protected override void afterUpdate() {
        System.debug('Account updated: ' + Trigger.newMap.keySet());
    }
}

◆ Step 3 – Create Or Update Account Trigger

If Account trigger already exists, update it instead of creating a new one.

File → New → Apex Trigger

Object:

Account

Trigger Name:

AccountTrigger

Paste And Save:

trigger AccountTrigger on Account (
    before insert, before update,
    after insert, after update
) {
    new AccountTriggerHandler().run();
}

Example

Create a new Account.

Automatically:

Description = "Created via Trigger Framework"

Update Account.

Debug logs show updated record Id.

Why This Pattern Matters

Without framework:

● Logic scattered in trigger
● Hard to debug
● Risky changes

With framework:

● Clean separation
● Predictable behavior
● Easy expansion
● Team-friendly

Testing Strategy

● Insert Account → Verify Description
● Update Account → Verify debug logs
● Bulk insert multiple Accounts
● Confirm no recursion

Happy Coding! 🚀

Architecture today saves firefighting tomorrow.

Apex Beginner to Advance

Project 5 – Trigger Framework Implementation