Table-Driven Trigger Management and Why it Matters

Thousands of organizations of all sizes and missions use the Nonprofit Starter Pack (NPSP), and I love working with the NPSP team to make the product better every day. The NPSP has tons of features with some really sophisticated code behind the scenes. Sure, you can track Pledges and Recurring Gifts, User-Defined Rollups, and other rollups out of the box. But if you asked me what my favorite NPSP feature is, I’d have to say Table-Driven Trigger Management (TDTM).

Table-Driven Trigger Management—quite a mouthful. So what is it?

TDTM is a method for managing the behavior of your Nonprofit Starter Pack code, ensuring that things happen in the order you expect them to happen. For example, you wouldn’t put on your shoes without putting your socks on first, right? TDTM lets you tell Salesforce to ALWAYS put the socks on first, then the shoes, and so on. Otherwise, triggers fire in an indeterminate order, which is really just a fancy way of saying that potentially you could end up wearing your socks over your shoes (or have one piece of code firing before another, and not in the order you want).

Most users (probably more than 90%) have never heard of TDTM or have any understanding of why it matters to them. There is a fantastic technical article written by Carlos Ramirez Martinez-Eiroa (now working on Higher Ed Data Architecture, which also implements TDTM) that walks you through the technical details of this amazing feature. I’m here to elaborate on it a bit more, and explain why this super-technical-sounding thing is so great.

In order to understand why TDTM is so powerful, we have to take a step back and look at Apex. Apex, the programming language used to build automation in Salesforce, allows triggers to fire when a record is inserted, deleted, or updated. This means that Apex automation happens based on some criteria, very similar to Salesforce workflows, but a bit more powerful. Salesforce and many expert developers recommend that you have only ONE trigger for each object (like Contacts): one trigger to rule them all! But how do you make sure that people actually do that? It’s easy to mistakenly create a new trigger and end up with many triggers for the same object, which is absolutely *not* a Salesforce best practice.

But why does this matter so much? I can create a bunch of triggers and workflows for one object, you say, and that will take care of things. Well, the problem with Apex is that if you have many triggers for the same object, you have no guarantee that they will fire in any specific order! (It’s simply an Apex limitation—no way around it.) So your trigger to update a Contact record updates the record, which then potentially causes another trigger to fire and update the same record with some other, conflicting information. Oops. That’s almost as bad as putting socks on over your shoes! Or…you choose to make something rely on another trigger firing first: first update this field, then use the value of that field to calculate something and update a related record. If these are separate triggers, you can’t guarantee they will happen in the order you want. Combining everything into a single trigger in Apex allows for much more control over the exact ordering of automation.

So that’s the way you want to do it. But what if you’re an Admin who doesn’t necessarily know Apex, and you want to adjust the order in which things happen?

That’s where TDTM comes in! TDTM allows you to easily rearrange the order of things via a table in the Salesforce interface (hence, the “Table-Driven” in TDTM). With TDTM you can tell your Apex trigger: do X first, then Y, then Z. All without code!

In the screenshot, each entry in the table refers to a Class (in Apex, a Class is a bit of code that has a specific function). As you can see, users can modify the order of those classes for each object. (And, following best practice, all of these classes are called by a single trigger.)

Of course, this only works if your developer has already integrated this pattern into your code (and they should!) And as an Admin, you need to exercise extreme caution when rearranging these classes. Always test in a sandbox first, as modifying the table can have large impacts on your system.

The true benefit of TDTM comes as your nonprofit grows and requires more complexity. Maybe you want to add your own trigger with your own logic, or want to create your own integration with a custom system or any other database. Or maybe you just want to make sure that certain records are updated before they get synced to another database. TDTM allows organizations to grow and more easily add complexity to their code bases while still maintaining control over the order in which things happen.