recurring thoughts on recurring donations in the Salesforce NPSP

This post will read like “inside baseball” for people who are familiar with Salesforce, the Nonprofit Success Pack (NPSP), various iterations of the NPSP over the years, and other automation features in Salesforce. However, if you don’t regularly engage in those topics, I hope there’s still ideas worth discussing in here!

For more than 5 years, actually heck, more than 10 years (wow!), I’ve been thinking about how to best “deal” with donations that are processed in more than one transaction. Whatever we choose to call these MIDS* (Multi Installment Donation Scenarios) *[I made up this acronym]:

• multi-year grants (outbound and inbound);
• monthly recurring donors;
• pledge fulfilled from different donors in the same household; or
• any type of pledge that will be fulfilled in chunks

they all harken back to the same dilemma.

It’s so easy (HAHAHA) to track donations where the commitment and transaction essentially happen at the same time (for ex: credit card donation through online form). You just create a record for the donor (if there isn’t already) and a record for the gift, and VOILA! If there’s time lag between the commitment and the transaction (this is the “check is in the mail” type of scenario), we can use similar processes. But when the commitment comes in, and then multiple checks or credit card transactions occur, spread out over time, we start to break all of our rules!

I think this has stymied fundraisers, operations people, accountants, and database admins for time immemorial, so it’s no surprise that there are a lot of different ways to do it. To make matters even more complicated, each of those roles might have a different preference for what to do! To add insult to injury… they might each do it their own way at the same time! Eeek! “Even” Salesforce has changed its mind about how to structure MIDS, so much so that they have two or three different models/modules in circulation. If you find yourself flumoxxed by the world of MIDS, you are in good company.

MIDS are one of many tricky scenarios to record in a donor database, but certainly not the only one. So, here’s my requisite list of What I Don’t Cover in this Post:

• Gifts from Donor Advised Funds (DAFs) (unless they fulfill a MIDS)
• Bequests (even though they are often processed in installments)
• Employer Match contributions (even though they seem like installments)
• Two+ donations from the same person in a short time period (seem like a MIDS, but there is no expressed donor intent or pledge card)
• Peer-to-peer fundraising (seems like MIDS installments under the peer’s “campaign”)

options

It seems to me that there are a variety of options for how to model MIDS in Salesforce. Let’s explore them together!

1. Donation With Payments – I see this used most commonly for Grants. NPSP has functionality to automate scheduling payments according to interval rules. Official documentation says that this is the recommended approach for orgs that are on the Accrual accounting style.
   
2. (Legacy) Recurring Donations – I have used this module extensively and I really love it. There is a custom object where you can set the donation schedule rules, and then Salesforce automatically creates Donations according to those rules. You can update each donation when the transaction occurs, as well as use these Donations in projection reports.
   
3. Enhanced Recurring Donations – (came out in 2020) This module is “easy on the eyes” and solves some problems that were not addressed in LRC (above), particularly the issue of skipping months or changing future payment amounts. Instead of creating all Donations at once, this module creates one installment ahead. When that installment is paid, the code will create the next one according to the schedule/rules.
   
4. Custom “Pledge” Object – If you want to group donations according to a pledge, and there are multiple types of pledges at play, or multiple data points about each pledge that you want to keep track of, but you don’t need automation for scheduling out installments, or you have some reason to not use NPSP, then this would be the way to go. However, I must admit, I’ve never needed to go this route!

my opinion

(This is not even my biggest hot take!)

I’ve written and re-written my suggestion paragraph so many times. I’m even noticing some impostor syndrome coming up. Do I know enough about this? Why should people trust me on this? Here’s my hot take:

• I think Donations with Payments are a terrible pain in the butt, and should be avoided at all costs
• I prefer Legacy Recurring Donations > Enhanced Recurring Donations, but it’s not a “big deal” to be on one or the other

For long time readers of this blog, you might be surprised that I’m taking such a strong stance on this, since usually I like to look at issues from all sides and take a medium “here are the pros and cons, but you can make any of them work! it depends!” type of stance. I’ve probably said “it depends” more than almost any other phrase! This is one situation where I’m going out on a limb and… I think it might NOT depend. I think this data model really *is* the right fit for all scenarios that I can think of. Next, I’m going to explain why.

what are the problems with “Donations with Payments?”

Hear ye, hear ye, the official documentation says that Donations with Payments are best for “accrual accounting.” I have a bone to pick with this, and not a little fish whisker bone. A bone the size of a femur! First of all, how many people reading the docs have a foundational understanding of accounting models? Answer: very few. (Reader, behold, I am the former treasurer of my synagogue. I actually do know the difference between Cash v Accrual accounting, but it’s not worth explaining in depth here).

Secondly, the definitions provided do not provide evidence for their recommendation. If all that is required for Accrual accounting is a “pledge date,” any solution could be customized to accommodate this. The division of responsibility between fundraising and accounting teams, and data, and between bespoke systems, deserves a lot more attention… OR don’t poke it with a 10 foot pole!

Moving on from these semantics, I find there are 2 serious pitfalls of this data model, both of which are difficult to recover from without extensive configuration AND training. Helpful for us, they both violate the same enduring principle:

Like goes with like

In my view, a Donation is a transaction should have a 1:1 relationship. Each donation is the same as a check or credit card payment. If we meant anything otherwise, why call the object “Donations” and each record, “a donation?” By splitting a “Donation” into parts, where each part (payment) is basically… a “donation,” we lose clarity in the data model. And more alarming, we lose the ability to run reliable reports and rollup fields.

If I want to answer a question like, “how many outstanding donations do we expect to receive this year?” I typically run a Donations report, where the stage is “Pledged” (or equivalent concept). But if we are using Donations with payments, we may have a Donation where part of it is paid last year, part this year, and part next year. We are faced with the unfortunate predicament of running two reports – one on Donations (for pledged, single-installment gifts) and one on Payments (for outstanding donation installments). This hardly seems like an efficient model.

Perhaps you are thinking, “Sam, you silly nincompoop! You can get around that problem by creating Rollup Fields on the Donation object to summarize the Payment records!” This is the second serious pitfall of the D&P model. The only* way I can see to make it work would require reproducing all of the Rollup fields that we typically use on the Contact and Household on to the Donation so that we can run reports on “Donation Amt Paid This Year” “Donation Amt Paid Last Year” “Donation Amt Pledged Next Year” “Overdue Donation Amt” and so on. Why would we want to recreate all of this work and introduce even more redundancy? Just a few weeks ago, I troubleshot a difficult reporting issue where Household rollup fields were mistaken for Contact rollup fields of the same name. We already have the ability to count up Donations. It makes so much more sense to me to use what we have!

*There is one, perhaps, obvious way to avoid the Rollup and Reporting pitfall. We can forgo reporting on Donations entirely and switch everything to Payments. This requires that we have the setting turned “on” for NPSP to automatically create Payments for all Donations. This *could* work. My objection is that this creates a lot of data redundancy, given that MOST donations are one-off gifts (one installment), which means that the Donation and the Payment essentially represent the same thing. For orgs with data storage issues (which is relatively uncommon in my network), this would be another thing to consider. Although most us are fine on that front, so it’s not the most compelling argument.

What’s wrong with going Full Steam Ahead with Payments if storage isn’t an issue? First of all, this violates another enduring principle:

Measure twice, cut once

(we don’t want duplicates or false duplicates, data that resemble each other, causing confusion and redundancy in the system!). Also, this approach renders us in the same data model as Recurring Donations (one object to “hold” groups of installments, one for the installments themselves), without the benefits of Recurring Donations.

what makes Recurring Donations so great?

If you’ve made it this far, you might be wondering how I got in the pocket of Big Recurring Donations. Well, since the NPSP is open source, I can assure you that I’m not being bribed. In fact, I’m paying with sweat equity!

The answer is, I think the RD model is smart and elegant. Furthermore, the automations that are included in the NPSP (both Legacy and Enhanced versions of the RD module) are strategic and reliable.

It’s not a new idea that we need to be able to create “groups” of donations by “type” or by other factors. We use lots of tactics to do this – Campaigns (group by “tactic” or by “year), Record Types, GAU (another module in NPSP), reports with summary rows, etc.

The new idea that I’m exploring here is using the RD module for more than “Recurring Donations” in the traditional sense (like monthly donations to NPR in the annual pledge-a-thon). In fact, I propose that we rebrand “Recurring Donation” to be “Pledge Fulfillment Schedule.”

In fact, I propose that we rebrand “Recurring Donation” to be “Pledge Fulfillment Schedule.”

If we start thinking of RDs as a Pledge Fulfillment Schedule, it will naturally incorporate the “monthly donation” MIDS type, as well as others, like grants, pledges, and maybe even bequests (oops- I said I wasn’t going to talk about those- forgive me! hehehe).

my top tips for configuring Legacy Recurring Donations

You might be thinking, “Legacy” sounds sooooo obsolete. That’s a reasonable objection and I encourage you to explore Enhanced Recurring Donations, especially if you are new to Salesforce + NPSP, and/or if you are using third-party apps to connect to Salesforce. Apps are most likely optimized by now for the Enhanced version. That being said, I think Legacy RDs have some distinct advantages for reporting, and also, I just know them a bit better, so I wanted to document here what makes them such a compelling pick.

1. Since the LRD module can create installment donations up to 5 years into the future (or longer if you set the settings accordingly), I suggest creating some projection reports (group by year) to help your team forecast pledged donations in future years!
   
2. While you’re making reports, also create some standard reports that show active RDs with grouped Donations under. This will make it easy to see the progression of each donor’s pledge commitment. RD also includes some standard rollup and formula fields for the amount completed and remaining for each RD “pledge.”
   
3. Last reports suggestion: Create reports that show overdue donations. Fortunately, using the RD data model, you can run *one* report for single-installment-donations and multi-installment-donations that are still “open” past their “close date.”
   
4. In LRD, you are required to select between Contact and Org fields to associate the RD to a person/household/organization/business/foundation/what have you. I suggest making Record Types (which is a rare suggestion from me!) for Individual RD and Org RD (which could be further divided into Grant / General) to make data entry easier and more consistent. Follow this up with creating Quick Actions to easily access the appropriate form and add the Quick Actions to the appropriate page layouts.
   
5. (we meet again…) If you are using “accrual” accounting, or for some other reason, it is important to you to record the Pledge Date, I suggest creating a Formula field on the Donation which can be populated one of two ways: (1) if single installment donation, populate with the date the Donation Stage is populated with “pledged” (or equivalent); (2) if MIDS, populate with the date the Pledge Fulfillment Schedule (aka Recurring Donation) begins
   
6. In NPSP Settings, you can select an option to copy the Campaign from the RD to each “child” Donation. I generally recommend taking advantage of this feature.
   
7. In NPSP Settings, you have the opportunity (hehe) to create naming conventions for Donations and RD records. Here’s what I suggest for Donations (which incorporates the installment number, such as “TDAA – Donation 4 of 5”)

8. If you create a naming convention that includes Close Date, be warned that this name will *not* update if the Close Date changes – and let’s be honest, when is the Close Date set in stone? I recommend designing a Before Save Flow to update the record name when the Campaign OR Close Date change… or you can train users to use the “Rename” button or run periodic batch rename jobs (also in NPSP settings). Beware that the batch job is the “nuclear” option – it will also rename custom-named records to conform to the naming convention.

9. This is a cultural practice, not a technical solution. I encourage you to store Pledge Cards (if you collect them!) on the Recurring Donation rather than on the first installment donation/all of the donations/the Household. It just makes so much more sense!

one weird thing

and I would love your thoughts!

If you are engaged in “moves management” in an intentional way, and you are recording stage changes and activities on the Donation before an ask or a pledge is issued, and then the donor ends up wanting to do installment gifts instead of a lump sum amount, how should this be handled?

Here’s how I handle it, but I’m wondering if there’s a better way out there!

I create an RD and auto-create the installment Donations. Then, I delete the 1st Donation in the series. Next, I take the Moves Management donation and connect it to the Recurring Donation record (this becomes the first donation, and I rename it accordingly).

in conclusion

I know I raised a lot of ideas here and used more jargon than I usually do. Please give me feedback in the comments about your reaction to this!

The big takeaway here is, Legacy Recurring Donations are my favorite available option for modeling MIDS, multi-installment donation scenarios (made up acronym). In fact, I like the data model so much, that I want to broaden it beyond “recurring donations” for all MIDS. <Please poke holes in this in the comments – but do it nicely!!!!, I’d love to hear of an outlier example that does not make sense>. With proper setup steps (see prior sections), this can become a powerful vehicle for a data-driven fundraising department, or a fundraising dept that doesn’t describe itself as data-driven, therefore wants the easiest and most streamlined option for tricky use cases.

I used two principles of good design (I completely made them up, no footnotes here):

1. Like goes with like, and
2. Measure twice, cut once

to explain why we should keep all transaction-oriented info on the Donation record, and pledge-oriented info on the Recurring Donation record.

I’m excited to circulate this post in the nonprofit Salesforce and nonprofit fundraising communities to see what “sticks” and have some open dialogue. Don’t be a stranger, I’d love to hear from you!