Skip to main content
Content Starts Here
This is a publicly shared Knowledge Article from the Power of Us Hub - an online community for nonprofit and higher ed Salesforce users. Join the Hub.
Product Documentation

Table-Driven Trigger Management (TDTM) Overview for HEDA

Introduction

Table-Driven Trigger Management (TDTM). Quite a mouthful. Kind of sounds like it might be an anger management technique. Actually it's a tool to manage your code in Salesforce and control how Apex behaves. Apex is the programming language used to build complex automation in Salesforce, and TDTM is a framework for managing that code. Intriguing, yes?

We're here to demystify TDTM—what it is and why it's such a powerful tool for nonprofits and higher ed institutions using applications like the Nonprofit Success Pack (NPSP) and the Higher Education Data Architecture (HEDA) from Salesforce.org.

What Is TDTM?

TDTM is all about automation.

Automation is one of the big benefits of Salesforce. For example, when a Contact record in Salesforce is added, updated, or deleted, we often want other things to happen automatically—update an address or a value on an Account. You may be familiar with using Process Builder or workflows in Salesforce to automate business processes. Some of the more complex processes are built with another automation tool called Apex triggers. Apex triggers are simply another way of handling automation, using code rather than a feature like workflow.

HEDA relies heavily on triggers. For example, a trigger on the Contact object can automatically update address data when the Contact is updated. Other triggers are used to roll up or summarize data from related records to a parent record. Triggers come standard with HEDA, and TDTM is the framework for managing them.

In practice, TDTM has several uses. TDTM lets you:

  • Disable specific pieces of code
  • Build your own custom code that works in conjunction with HEDA
  • Control the order in which the code executes

Disable Specific Pieces of Code

Why would you want to disable code in your database? Shouldn't automated processes be running all the time? Well, it depends. For some organizations, there is no need to disable anything. For others, you might need to control when, or even if, certain pieces of code will operate.

You might need to disable code when you:

  • Import large sets of data (many thousands of records at once)
  • Integrate with external systems
  • Troubleshoot code errors

For more about disabling code with TDTM, see Disable Trigger Handlers.

Create Your Own Custom Code

If you're developing your own custom Apex code or integrating an external system with Salesforce, you should familiarize yourself with the TDTM architecture. Salesforce and many expert developers recommend that you have only ONE trigger for each object (one for Contacts, one for Accounts, and so on). One trigger to rule them all!

It's easy to mistakenly create new triggers and end up with many triggers for the same object, which is absolutely not a Salesforce best practice. When you learn how to extend TDTM functionality into your code, you don't need to create new triggers—you just use the trigger that already exists in TDTM to pass environment data to your custom Apex classes. By using the existing TDTM infrastructure instead of creating your own, you get the most reliable and efficient behavior as a result.

For a technical deep dive into TDTM design, see Table-Driven Trigger Management (TDTM), a great blog post by our own Carlos Ramirez Martinez-Eiroa.

Control the Order In Which Your Code Executes

If your organization has been using Salesforce for a while, it's likely that you'll identify where more automation could save time. For example, you could turn several clicks into a one-click operation or update groups of records in a nightly batch process. While tools like Process Builder and workflow can do some of these things, custom Apex code is sometimes more appropriate. As you develop custom code, it becomes really important to manage the order in which your code fires, which is why TDTM is so helpful.

Why's that?

TDTM ensures 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, things happen 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). Apex triggers do not come with a way to control the order of operation but TDTM fills that gap.

Summing Up

By now, you might be thinking: Wait, this all sounds pretty technical. We're just getting ramped up on Salesforce . . . Do I really need to learn about this feature?

The short answer is yes, but customizing TDTM might not be for everyone right away. As we've seen, TDTM allows organizations to grow and more easily add complexity to your databases while still maintaining control over the scope and sequence of your process automation.

If the examples we've covered don't sound like the sorts of things your organization is doing now, or you only partially followed what we're talking about, then chances are it's OK for you to leave the default TDTM behavior as is. However, organizations do change over time and you may find that you need to engage with TDTM down the road. Just put a pin in it for now and remember its intended use for the future.