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.
Thank you for posting this. I’ve gone through all the steps and set up and activated the two processes. However, I can’t get them to fire when I save the opportunity or hit the Email Acknowledgement button, as you suggest I do. There must be some step that is missing that will activate the processes, I think. Please let me know.
Thanks for the feedback – it’s really helpful to know that people are putting the info to use. I’ll reach out to you privately to try to figure out what the missing piece is, and revise the piece accordingly.
Any updates on additional steps needed? I too went through all of the steps but didn’t have success when hitting the Email Acknowledgement button. I really appreciate the insights. I’d love to be able to have our Email Acknowledgment button work and be able to send appropriate responses. Thanks!
When Eric was having trouble, we tested and poked and everything seemed like it should work. . . and then it started working. We didn’t think we had changed anything along the way, and I don’t think we ever figured out what happened such that it started working. But it did. . .
There are a few obvious things to try – are the email templates active? Are your tests actually meeting the criteria to fire the flow steps?
This is great, I did a modified version of what you presented here and got it to work. So awesome! Here is one question: no matter whether the email was actually sent or not (based on criteria I set up in my process) I still get a message saying that the acknowledgement was sent. Any advice on how to only display a success message when it fired successfully, and an error message when it didn’t (mimicking the standard email acknowledgement messages)?
Thanks, glad to hear it! I’ll see what I can do about the messages, but not sure how soon I’ll be able to have a look.
I am running into the same problem as Dan with the acknowledgement sent message. Was there a work around?
Thanks Scott! Being an old programmer, this framework was very easy to use and follow! I implemented this in a backup database and it says that an email was sent – but I never receive it. It does change the two fields – so I’m hoping it is just that the Salesforce partialdb doesn’t do emails.
I feel comfortable with the work involved and will move it to prod and test appropriately with dummy data.
Sandboxes, by default, don’t allow this type of email to go out. You can go to Setup > Email Administration > Deliverability and set Access Level to All Email. Just be careful about what emails you trigger.
One important thing to remember is that if you’ve got any criteria using Salesforce IDs is that you must use the 18-character version or the criteria will always come back as false.
Hi! Not sure if this thread is still active but…
I have the built-in NPSP Workflow set up (may use your Process Builder in the future, thank you for posting!) but I wanted to adapt the workflow so that the SDOC related to the Opportunity (we have it generated automatically from SDOC templates) would be automatically attached to the email and sent with the template. Is this possible, to configure a Workflow to attach a related SDOC to the Email Alert? Or would/could it be done through Process Builder? Thanks!
Even process builder uses the old-school email alerts to send emails, and I don’t think that there’s any way to include a dynamic attachment with either Process Builder or the Workflow Rules. Something like this approach can include a dynamic attachment, though it might need some work to use SDOCs, unless they’re stored as static resources.
The easier approach would probably be to create a formula that provides a link to the SDOC and add that to the email template, allowing the recipient to click through to it, rather than trying to attach it. Not perfect, but a lot less work.
Hello – this is a great resource – I haven’t tried it yet but will. I’m wondering if the same process can be built for the Payment object? We acknowledge gifts based on payment records because we may track multiple payments within one opportunity.
Yes, you can do the same for Payments.
Hi. Thank you for posting this solution. I’ve set everything up according to the instructions (I think), but must be missing something. When I select records from the list view and click the Email Acknowledgments button, I get this error:
NPSP did not send acknowledgements for the following records. Acknowledgements can fail if there is no workflow rule (Acknowledgement Status EQUALS ‘Send Acknowledgement’) activated to send the acknowledgement, or if the records did not meet additional criteria to trigger the workflow rule. For example, if Primary Contact is not set, or if the Primary Contact’s email field is empty or invalid.
All the records are updated to Email Acknowledgment Not Sent. I have deactivated the standard WFR, so that the default email is not sent.
I have confirmed that the Primary Contact email is not blank.
What step am I missing?
Hi Scott – This flow is amazing and is going to save our staff member tons of time! I was able to get it to work for me (as Admin), however when she clicks on the Email Acknowledgements button it gives an insufficient privilege error. Would you happen to know where I can give her permission?
She has full access to the donation/opportunity objects and email templates. She owns and creates the donations as well.
The first error seemed to involve apex classes (util_pagemessages and Util_HtmlOutput_CTRL). I gave her access to that which then caused a generic Insufficient Privilege message to reach out to the Admin. I’m lost – and posted on powerofus hub, but wanted to reach out to you as well.