Pros and Cons of New Trigger Functionality in Cumulus

If you've been on the Hub or following Salesforce nonprofit news lately, you know there is a new release of the Nonprofit Starter Pack called Cumulus. You can check out our consultant Michael Smith's initial impressions on Cumulus here. Recently Mike reviewed the pros and cons of the new trigger functionality in Cumulus on his Force2Be blog, which we have excerpted here. This change does not mean much for normal users, but for developers you now have nearly unlimited flexibility in determining the behavior of the NPSP for your customers, clients or organization.

Beginning with the upcoming NPSP Release 3.0 (aka Cumulus), all trigger functionality is controlled through TDTM. As defined in this hub article:

Table Driven Trigger Management is a new method for managing the behavior of your Nonprofit Starter Pack code. Instead of each piece of functionality being driven by its own trigger, there is only a single trigger on each object. That trigger then calls a database table that provide a list of code to run in conjunction with the trigger action.

While migrating a client to the new version of the NPSP, I set out to see what TDTM could do. Before delving into the code, here are some pros and cons to using TDTM for your triggers:

Pros

• Obviously, your custom code will work and play quite well with NPSP Triggers
• Provides superior control over the execution order of your code, both relative to NPSP Triggers and relative to your own customizations. Anyone who has followed the single-trigger-per-object pattern in the past will be familiar with this already.
• Relatively straightforward to implement

Cons

• TDTM is only available for a small list of objects: Account, Contact, CampaignMember, Opportunity, and the key NPSP objects (Address, Relationship, Affiliation, Household, RecurringDonation). As of this blog post, it is not possible to extend the use of TDTM to any other objects. There is an open story on Github for this here.
• Apex Unit Tests that do not use SeeAllData=true will not run your custom TDTM Trigger code unless you recreate the TDTM records prior to creating your test records. The packaged TDTM triggers will run even with SeeAllData=false. In my sample code below, recreating the custom trigger handler references is handled through the custom InitTDTM() method. There is an open story on Github for this here.
• Any custom TDTM Trigger records created in Production will not be copied to a new or refreshed Sandbox and must be recreated in that org. As with above, any NPSP standard Trigger Handlers are automatically recreated in the Sandbox either by visiting the Settings page, or the first time you create a record for one of the objects Cumulus interacts with.
• Custom apex code errors are masked and logged to the NPSP Error Log. This prevents your users from getting long apex error messages due to code problems, however it also complicates the debugging process. In particular, testing of code logic through Unit Tests (though this is best practice) are affected here because the code just doesn’t run with no visible explanation. System.Assert statements are key to identifying where a problem may exist, however debugging the exact root cause may be a challenge.

For more information on implementing custom triggers, head on over to the full post on NPSP Table Driven Trigger Management (TDTM) on the Force2Be blog.