With Web-to-Lead and Web-to-Case forms, Salesforce provides an easy way to connect your constituents to to your Salesforce database. All it takes is a few clicks: select the Lead or Case fields you want to include, and like magic Salesforce...
A Single Merge to Rule Them All
It’s often a thankless task, but sending out Thank You letters is an important part of the development process. These letters give nonprofits yet another way to engage supporters so it’s important to personalize their message whenever practical.
Enter Apsona and Apsona Document and Email Merge. Nonprofits can leverage these powerful, but inexpensive utilities to produce custom acknowledgment letters for print or email and do so with only single generation of merged letters.
Let’s use a real-life example to demonstrate what we mean.
Let’s say a nonprofit receives 200 donations one week and they break down as such:
- 100 received with no indication of what campaign generated the donation
- 50 received at a dinner gala to support a specific program
- 25 received because of an end of year campaign
- 25 received in advance of a summer fun run
In the above situation a nonprofit has a couple options:
- Send 200 acknowledgments with a generic thank you and no mention of what prompted the gift
- Send custom acknowledgments with a message specific to the encounter that generated the donation.
The first option above is typically the fastest, but also the least satisfying. The second option is best, but often requires generating multiple document merges, one for each campaign, and that can become time-consuming for staff. Utilizing a little trick we developed, a nonprofit can get the best of both options: efficiency and greater customization.
An Overview of the Solution
The solution relies upon each active Campaign having an Acknowledgement Letter field containing the main body of an acknowledgment letter. In addition, each Donation record should identify the relevant Campaign above via the Primary Campaign Source field. If the relevant Campaign isn’t known then utilize a default or placeholder Campaign.
Utilizing an Apsona report and merge action, these fields link each Donation to the appropriate acknowledgment Campaign for purposes of merging the relevant text into an Acknowledgement letter.
Configuring the Acknowledgement Solution
The configuration isn’t horribly difficult; however, it requires a familiarity with creating and editing Salesforce fields, updating page layouts, creating Apsona reports and merge actions, and creating a MS Word document with appropriate merge fields. Below is a high-level overview of the configuration.
Step 1 - Fields
There are four Salesforce fields required:
- Acknowledgment Letter - Create a long text field on the Campaign object and set the number of lines to at least 20. The field should be added to all relevant Campaign page layouts.
For each active Campaign that may generate donations, be sure to populate this field with the body of a corresponding Acknowledgement letter. The body should consist of all text beginning after “Dear …” and should include a sign-off such as “Sincerely, Executive Director.”
- Primary Campaign Source - This is a standard Salesforce Donation field that already exists although it should be made required to ensure all future donations have a Campaign value. This field will identify what Campaign for the proper acknowledgment letter. Alternatively, if there is concern about using this standard field, then consider a custom Donation field that looks up to a Campaign record.
- Acknowledgment Status - The Nonprofit Success Pack (NPSP) includes this field. Creating the following picklist values if they do not already exists and ensure the field has been added to all relevant Donation page layouts:
- To Be Acknowledged (set this as the default value for the picklist)
- Do Not Acknowledge
- Acknowledgment Date - The NPSP also includes this field so ensure it is visible on all relevant Donation page layouts.
Step 2 - Merge File
There are two key elements to remember.
First, you’ll need to create an Apsona-friendly MS Word template. For more about how to create a merge template.
Second, you’ll need to upload the template to Salesforce Documents so that it is available to Apsona. This document should include a merge field that will be a placeholder for the Acknowledgement Letter text. To see a simplified merge document.
Step 3 - Apsona Single-Step Report
Create an Apsona Donation report. This report should include any relevant Donation, Account, and Contact fields, as well as the fields indicated above. This ensures the text of the Acknowledgement letter is available for merging and for updating of the Acknowledgement Status and Date fields. For more about creating Apsona reports.
Step 4 - Apsona Merge Action
Finally, you’ll want to create an Apsona Merge Action to complement the report above. For more about creating Apsona Merge Actions. This action should do each of the following:
- Identify the Salesforce Document above for merging
- Map the merge fields, including the Acknowledgement Letter field
- Set the Acknowledgement Status to Acknowledged
- Set the Acknowledgement Date
- Generate a single MS Word document for printing
- If desired, create an Activity entry for each Donation acknowledged
The approach outlined above is simply one approach. There are a number of ways it can be adjusted to meet your nonprofit's needs. For example, some nonprofits will prefer to email these acknowledgments while others might prefer a different set of actions upon creation of a merge document.
We Can Help
Of course, every Salesforce instance and every nonprofit’s needs will vary and that’s why Now IT Matter’s is here to help. In addition to configuring solutions such as this, we also help clients think about how to streamline and enhance current processes so they aren’t stuck with a one-size-fits-all solution. If you think this solution might be for you then give us a call so we can talk more about your nonprofit’s needs.
#LevelUp with Process Builder
In a world led by technology, automation is key to saving time and creating user-friendly processes.
Process Builder is a powerful tool that delivers automation in Salesforce and was specifically created to help you overcome the anxiety of and processes of automation.
Technology recognized best practices ensure you are maximizing opportunities with Process Builder, thus eliminating error messages and emails. The five best practices noted below will help ensure you make the most out of automating with Process Builder.
Tips & Tricks
- If you’re referencing related objects, make sure they exist.
When using information from fields in a related object to populate a new record, update an existing record, or set a variable in a flow. It’s important to ensure the relationship exists before pulling information from the related record.
For example, if you want to update an Opportunity/Donation’s Close Date to match the End Date of the Campaign it’s related to, you need to build and activate a Process Builder. If an Opportunity gets created without a Campaign, however, then a “Flow Trigger” error will occur. To avoid the error, ensure the Opportunity is related to a Campaign (see example below):
When evaluating formula versus using criteria simply add the following criteria in the formula:
NOT(ISNULL([fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"][Opportunity].CampaignId ) )
Including this additional criteria will prevent the Process Builder from looking for information that is not available.
- Use Set Conditions instead of formula criteria.
The old Salesforce adage of “clicks over code” applies here as well. The Set Conditions in Process Builder can do a lot more than what you may be used to with Workflow rules. For example, not only are the Set Conditions easier to read, but the validity is more stable than the formula builder.
Formulas are used for analyzing criteria that aren’t available in Set Conditions; the prior value of a field, for example. As a precaution, the formula editor in Process Builder does not have the same level of syntax/error checking as it does in Workflow and Validation rules. Therefore, formulas must be tested to ensure accuracy.
- Test and Deploy Process Builder to a Partial or Full Copy Sandbox first.
Some want to rush the “go live” process; by activating a Process Builder in Production. It’s easy to do, but not efficient as it can creates errors and bad data that are difficult to reverse. Therefore, it’s important to build first in the Sandbox. Finally, test, test, and test again before deploying to Production.
Note: When deploying Process Builder and using a change set the latest version of the Process will be saved as an “inactive” version. As a result, it is necessary to open the Process, activate it and then it will go live.
- Whenever possible, use the RecordType.Name instead of the ID in your criteria.
There is some debate around this issue, some say it’s best practice to use the 18-character Record Type ID instead of a name. Names can be changed, but ID’s remain the same.
Now, if following best practice #3 to create a Process Builder in a Sandbox, the Record Type ID will change when you deploy it to production. The Record Type Name, in contrast, will stay the same. Minimizing the number of changes made in Production is preferable, but you will need to remember to update Processes if Record Type Names are changed.
- Keep track of your Processes and Workflow Rules.
There is a lot of overlap between what Workflow Rules and Processes can create overlap, so it’s a good idea to create a plan to help keep track of them and ensure a Workflow Rule and a Process are running in parallel.
The best way to ensure there is no duplication is to give priority to one rule/process over the other. For example, make it a priority to use Process Builder for all process automation unless it can only be done by a Workflow Rule (for example, sending outbound messages). Doing so will ensure the automated process is easy to locate. Or, keep track of the automated processes on a separate list or spreadsheet (which notes the object and identifies it as a Process or Workflow Rule).