Revamping the NPSP Email Acknowledgement Workflow Rule to Allow for Multiple Acknowledgement Email Templates

I have seen a couple of users on the Power of Us hub asking how to use different email templates for different types of donations. On this episode of Workflow Rule Makeovers, we’ll take the default NPSP workflow for sending the email acknowledgement and make it into a process builder process that allows you to use different templates based on your criteria.

(In the interests of transparency, I’ll mention that you can accomplish this same result with a series of workflow rules with complicated criteria, but it will be much more difficult to manage when you need to update any of the conditions, and you run the risk of creating overlapping rules that will send multiple, different thank you emails to your valued, but possibly easily annoyed, donor. Heaven forbid that it might also be your board chair. If you need more persuasion about using process builder, see this post.)

Before you get crazy with the cheese whiz, though, consider using formulas to create the necessary differences between your outgoing email acknowledgements. If the text differences between your templates are minor in scope but crucial for donor relations, this can make it easier to manage your flows and your email templates. Even if you’re using different email templates and a process to pick the right one, formulas can help reduce the number of necessary templates while improving personalization.

This post is the companion piece to Little Nonprofit’s Adventures in Process Automation, which gives an overview of basic process automation tools, as well as some tips and tricks.

The standard NPSP workflow rule that sends an email acknowledgement is called Opportunity Email Acknowledgment, and you can find it under workflow rules in setup. It evaluates a formula to see if it’s time to do its thing, and then has three resulting actions – two field updates and an email alert.

In the interests of simplicity and clarity, I am going to create two separate processes – one that selects and sends the proper email template, and one that invokes that selection process. But first, you need to create the email templates you’ll be using.  You can save yourself some time by basing your email templates on the standard NPSP Opportunity Acknowledgment email template that you’ll find in the NPSP Email Templates folder.

For the sake of my demonstration, I’m going to base the choice of email templates on the Opportunity Record Type, of which I’ve set up two: Membership and Donation, each with their own email template. You can set up your own criteria as needed once you’re in the process builder, based on other Opportunity Record Types, Primary Campaign Source, custom fields, or other factors in any combination.

First we’ll build the selection process. It’s going to be a new process that will be started when invoked by another process.

Once you hit Save, you’ll find yourself in the midst of the action in the process builder. Select the Opportunity Object, then click Add Criteria. For my example, I’m sticking with the default for defining criteria, “Conditions are met,” allowing me to navigate to my field and then define what it should be evaluated against. My field is Opportunity>Record Type ID>Name, and I’m looking for the string value Donation.

After saving this step, I click into immediate actions, and select the Action Type Email Alerts. I give my action a name that will make sense to me later.

But while I have created an email template, I haven’t yet created an email alert, so I click the ‘create one’ link, and fill in the necessary details. You can also use the existing email alert for the NPSP thank you process as a model. Note that the NPSP offers honoree and notification recipient contacts as additional related contacts. You can include them, or set up separate notifications when those contacts are populated.

After saving this, and repeating the process for my membership email, my two-step selection process is ready to go. I can activate it safely; it won’t cause any emails to go out until it has been invoked by another process. At this point, I might add another step to provide a catch-all acknowledgement, in case I later have some other type of Opportunity and forget to add a step in my process, or in case the previous criteria aren’t met. But if there are cases where you don’t want an email going out (for grants, or in-kind donations or what have you), you wouldn’t want to add a catch-all. Note that each action sequence ends with the process stopping – you can edit that to allow the process to keep evaluating further criteria and acting, as appropriate. But in this case, we don’t want donors getting a variety of different thank you emails, so it makes more sense to leave it as is. Once you have sent one email, don’t even think about sending another! When working with more complicated criteria, this helps you avoid any negative consequences of writing ambiguous or overlapping conditions.

Now, we need to create the process that will start the ball rolling on this email. Again, we are starting a new process, but I’m going to give a generic name, Opportunity Processes, in anticipation of adding other steps later. A strength of the process builder is its ability to evaluate multiple criteria and act on any or all of them. By putting your Opportunity automation together in one process, it is much easier to find and update criteria or actions as your process automation increases in size and complexity. Select the opportunity object, and indicate that you want this flow to start when a record is created or edited, not just created.

Unfortunately, setting up the criteria is not as simple as pasting in the formula from the existing NPSP Workflow Rule – the Opportunity fields need to be addressed slightly differently, prefacing them with [Opportunity]. as below in the screenshot, as well as a more easily pasted code snippet. Note that you do want to open the Advanced section, and specify that ‘you want to execute the actions only when specified changes are made to the record’ to prevent any subsequent edits to the record from causing extra emails to go out.

And here is that formula, for your cutting and pasting pleasure:

TEXT([Opportunity].npsp__Acknowledgment_Status__c) = $Label.npsp__sendacknowledgmentfirestatus &&
 [Opportunity].npsp__Primary_Contact__r.Email <> NULL &&
 [Opportunity].npsp__Primary_Contact__r.npsp__Do_Not_Contact__c <> True &&
 [Opportunity].npsp__Primary_Contact__r.HasOptedOutOfEmail <> True &&
 [Opportunity].npsp__Primary_Contact__r.npsp__Deceased__c <> True

If you recall from the original workflow rule, we have three pieces of business logic to complete: one email alert and two field updates.

To send the email, we need to invoke the process we built that will decide on and send the proper email template. Here’s what that step looks like after I’ve told the Process Builder that the action I want is Process, then selected the process, and told it to act on the Opportunity object. Just select your own invocable process here, and set the process variables as shown:

And finally, here is how we set the two field updates. For the second Immediate Action, select record update, and then indicate that you’ll be updating the Opportunity record that started the process. Then the two field updates, which were separate actions in the workflow rule, can be handled together.

Now tell your staff not to send any acknowledgements for a while, and launch and test your work. Activate this process, and give the standard NPSP Workflow Rule a pat on the back and deactivate it. Then set up some test opportunities with your email as the primary contact’s on the parent account, and hit the ‘Email Acknowledgement’ button. Check to be sure that the status and acknowledgement date are updated properly, and that you receive the proper email for each variation on the donation.

Then let your staff know it’s ready to go, and hover over them grinning as they check it out. Maybe they’ll be as impressed with you as you are with yourself!

If it for some reason isn’t behaving as expected, you can always deactivate the process and reactivate the workflow rule as you work out any kinks.