Whether you’re new to NPSP or you’ve been using it to manage your donors and donations for years, you’re going to want to know about some new functionality in the Spring ‘20 Salesforce release that will make it easier for you to automate the way your organization calculates soft credits.
What is a soft credit?
A soft credit is a credit for a donation that a contact or donor did not actually make, but may have somehow influenced. A common example of a soft credit is credit for a matching gift: if a donor gives $50 to your organization, and their company matches it, the total donation will be $100. The original donor therefore gave $50 plus a $50 soft credit, through their company’s matching gift.
Nonprofits like to track soft credits to capture the total influence that their contacts have on donations that they may not have given directly. Capturing this data accurately is important for accounting purposes, and for nonprofits to expand their fundraiser and donor bases.
Examples of soft credits include matched donations, donations given by another member of the household, peer-to-peer fundraising, donor advised funds, or donations that someone influenced by being part of a board.
Soft credits and opportunity contact roles in NPSP
In the Nonprofit Success Pack, or NPSP, you can track the original $50 as a hard credit (the actual donation itself), and the matched $50 as a “soft” credit because the donor influenced the donation, but did not actually make it themselves.
In the Nonprofit Success Pack, Opportunity Contact Roles are used to identify the contacts that are related to an opportunity (donation) and specify how they’re related. Soft credits and soft credit rollups (aggregate totals of different categories of soft credits) are tracked on the Contact record.
The Nonprofit Success Pack comes with a set of preconfigured Opportunity Contact Roles, but you can also create additional ones if you’d like to calculate your soft credits differently:
- Decision Maker
- Donor
- Household Member
- Influencer
- Soft Credit
- Matched Donor
The primary opportunity contact role (donor) will always receive a hard credit for a donation in NPSP. All other household members will automatically receive a soft credit role of Household Member on the same opportunity. NPSP has functionality, called Customizable Rollups, that aggregates soft credits to the contact or household record in a nightly batch. You can determine whether a particular contact role receives soft credit in NPSP Settings. This is the default NPSP setting, but it might not always handle soft credits the way you want for your organization
For example, imagine that you have a minor in a household who is receiving a soft credit every time one of their parents makes a donation, but in your particular organization’s case, you don’t want minors to automatically receive soft credits just for being part of a household.
The most straightforward way to handle this is to exclude these contacts from receiving soft credits in NPSP by excluding certain contact record types from receiving an automatic ‘Household Member’ opportunity contact role. This will work fine if you have all of the minors in the org assigned to a specific record type (for example if you have a contact record type that specifically defines “students” or “children”).
But what if you don’t have contact record types established or if your contact record types don’t necessarily identify who the minors in the organization are? Let’s look at another option that’s just become available:
New for Spring ‘20: How to automate processes with Opportunity Contact Roles
As of the Spring ‘20 release, you now have the ability to launch automation using our declarative tools (process builder and flow) to manipulate the creation of Opportunity Contact Roles.
Using this new functionality, we came up with a nice workaround to solve our sample issue of dealing with soft credits being assigned to minors.
Create a process that will launch whenever an Opportunity Contact Role (OCR) record is created, and automatically delete that OCR record if it pertains to a minor in a household. Doing this will remove the opportunity contact role and prevent this opportunity’s value from rolling up as a soft credit for that contact.
You’ll see our use case presented in the steps below, and you can follow a similar process to exclude soft credits from contacts fulfilling other criteria that you’ve identified.
We use a combination of process builder and flow to automate the deletion of the OCRs based on the specific criteria defined. We will go through the following steps:
Step 1: Create a Flow that will delete the record.
Step 2: Create the Process Builder to determine the criteria for launching the Flow.
Step 3: Have the Process Builder (from step 2) call the Flow (from step 1).
Follow the steps below to set this up:
Step 1: Create an Autolaunched Flow
Create a flow named “Delete OCR” which has a “delete records” element
The Delete Records element will delete the OCR record (which will be passed from the process builder in the following steps)
Step 2: Process Builder:
On the Opportunity Contact Role object: a process should start when the record is created
Criteria: if the opportunity contact role is “Household Member” and the contact is a minor (in our example, the contact is under the age of 19)
Step 3: Call the Flow
As the immediate action in the process, call the flow: DeleteOCR (which we created in step 1)
Set Flow Variables: name a flow variable OCR of type field reference with the value shown below. This will enable you to send the ID of the OCR record from the process builder to the flow for deletion.
Use this example as a template to help you in writing your own criteria to fulfill other business requirements that will automate the deletion of an opportunity contact role from a specific type of contact given your organization’s needs.
Check out the source of this process builder and flow here. You can spin up your own scratch org (Spring ’20 or later) and push the source to try it yourself!
Remember, that if you are dealing with a batch set of records — the recommended approach would be to use a Schedulable Apex class or Scheduled Flow so that you don’t hit SOQL limits.
