Building a Mini Trigger Framework in Apex

Apex triggers can get messy real fast. You start with a couple of lines and conditions, and before you know it, you’re neck-deep in nested if-statements, trying to remember which part updates what. So, we decided to clean things up a bit by building a mini trigger framework using interfaces.

Here’s how we did it.

Step 1: Define a TriggerFilter Interface

The idea was simple: We needed a way to filter records based on specific conditions. So, we created a TriggerFilter interface with a filter method. Each trigger would then have its own main filter class with its own inner classes. Every scenario we needed to handle had its own inner class that implemented this interface. This added structure to the code and made each filter easy to test and maintain.

‍

Step 2: Create Filter Classes for Each Scenario

For every use case, we made a separate filter class. One filter checks if records are new, another checks if they’re active, and so on. Each filter only worries about one thing, so the logic stays clean and simple.

‍

Let’s break down what’s happening here. This method is designed to help us figure out if a Contact’s Mailing State has changed to or from California (CA) during an update.

Step-by-Step:

• Prepare a List for Matches:

• We start by creating an empty list called matches. This will hold any records that meet our filter criteria.

• Cast the Records:

• The method receives two records: the old version (before the update) and the new version (after the update). We cast both to the Contact type so we can easily access their fields.

• Use the Insert Filter:

• We create an instance of another filter, InsertFilterMailingStateCalifornia, which simply checks if Contact’s MailingState is 'CA'.

• Check Both Old and New Records:

• We check if the old record was in California.

• We check if the new record is in California.

• Add Matches:

• If the old record was in California, we add it to our matches list.

• If the new record is in California, we add it as well.

• Return the Results:

• The method returns the list of records that were (or are now) in California.

In Short

This method is a handy way to catch any update where a Contact’s California status changes, so you can trigger rollups, notifications, or other business logic as needed.

Step 3: The Helper Method That Ties It All Together

Now that we have several filters, we have built a helper method to run them all. This method loops through each filter, applies it to the list of trigger records, and stores the result in a map. The key in the map is the name of the filter, and the value is the list of records that matched.

Step 4: Plug It into the Trigger

In the trigger handler, we passed in the list of filters and let the helper method do the filtering. We then handled each group of records by calling the corresponding business logic method. All the updated records were collected and saved in a single DML operation.

Why Bother?

• Readable – Each filter is focused and easy to understand.

• Reusable – We can use the same filter logic in multiple places.

• Testable – Filters are isolated, which makes writing unit tests super straightforward.

• Scalable – Adding new logic is as simple as writing a new filter and plugging it in.

This little framework has helped a lot in keeping our Apex triggers clean and manageable. It’s not overly complicated, but it keeps things from turning into spaghetti code. It is simple but effective. We went from messy nested if-statements to clean, focused filters that are easy to understand and test. Each filter handles one specific scenario, making the code more organized and reusable. If your triggers are getting out of hand, this approach can help turn chaotic code into something manageable.  

‍

If you would like to test it out, you can do so by using this link. Need help implementing this in your org? We're here to help.

‍