Moved from a thread on GitHub Discussions
NPPatch exists because NPSP mattered. It shaped how thousands of nonprofits manage their fundraising, their relationships, and their data on Salesforce. A lot of what it did, it did really well.
But it also accumulated years of decisions that made sense at the time and don’t anymore – features that never quite landed, UX that frustrated more than it helped, patterns that made customization harder than it needed to be.
Now we have a chance to do something about it. Not all at once, and not recklessly — but deliberately, with input from the people who actually use this every day.
I’d love to hear from you on two questions:
What did NPSP get right?
What should we protect? What works well enough that we should leave it alone, or works so well that we should build on it?
Think about the features, the data model decisions, the workflows — what do you rely on and want to keep?
What would you change?
What’s been a pain point for you or your clients? Where does NPSP get in the way instead of helping?
This could be anything – a specific feature that never worked the way you needed, a UI that confuses every new admin, a data model choice that makes reporting harder than it should be, something that’s just missing entirely.
There are no wrong answers here, and nothing is off the table for discussion. What we won’t do is break things recklessly – any changes to core behavior will be thoughtful, well-documented, and tested.
If you’re a consultant, an admin, a developer, or just someone who’s spent time in NPSP settings wondering why something works the way it does – this conversation is for you.
Replies: 4 comments · 2 replies
Okay @lmeerkatz, a few thoughts from an old curmudgeon who was there in the early days:
What did NPSP get right?
- I think the single biggest strength has been the simple and modular architecture since the beginning. There was always an ethos of “take what you need and leave the rest”, and although the 5 (or more?) packages model became cumbersome, the original idea was that you didn’t necessarily need all the packages, but rather you could pick and choose what you needed based on what your organization was going to actually use. Over time that obviously changed, but it started from “you don’t need everything, just get the stuff that you will use.”
- At the risk of sounding like a jerk, since I helped brainstorm what should be on it, the “Getting Started” home page with direct links to resources to help get folks using the app as quickly as possible. We definitely had more ideas here (guided walkthroughs, Trailhead modules surfaced, etc.), and some things weren’t implemented for a variety of reasons, technical and otherwise, but I think this was a really solid way to get folks up and running. If you can get to people while they are already in the system, it’s going to be easier than anything external (documentation, Trailhead, etc) every time.
- I know it was a little clunky, but I have a soft spot for the NPSP Data Import tool. One of the biggest issues with any new system is getting your data in there, and I thought it was an elegant solution to the problem of “what goes where” when all you have a list of people, where they live, and how much money they gave. I distinctly remember a late night at a Dreamforce bar talking with Nic Campbell and David Habib that this was a huge issue, as no one understood the “order of import operations”… and they just…BUILT IT.
- I have to say it: the community piece. I think people felt like they “owned” NPSP, whether it was through contributing to documentation, how-to videos, providing guidance to the product team, contributing reports and dashboards, or even code. That community spirit infused the product from way back to the original developer sprint, and, to be very blunt, is pretty lacking in any current offerings.
What would you change?
I need to think about what I would change. I know there are a bunch of technical things that need updating (e.g. workflows → Flow, Batch Data Import, removing the “clutter” from old packages) but I suspect there are other things, and I need to chew on those for a bit.
Hope this is a good start, and very excited to contribute!
1 reply
Seconding (2)!
I’m super excited to see that you already have an issue (#15 ) to break this up into multiple packages that share a namespace, though personally I’d keep common and constituents together. I think if that’s done, the individual pieces (fundraising, program management, possibly volunteers?) could be a bit more opinionated, because orgs can mix and match. It also makes upgrades easier if an org has heavily customized program management but wants to just keep the nPPatch-proscribed fundraising structure (or vice versa)
As a way of just joining this convo, I’ll post a few answers too:
What it got right:
- Household Accounts data model. Brilliant, powerful, useful.
- Affiliations and the Primary Affiliation field on contact, and the automation around it. Works great, easy to understand. Easy to use. Even does 90% of what you would want if you use a mixed data model (where some people are directly on their organization account).
- Relationships and management of reciprocal relationships is really cool. I know most orgs don’t use it that much, but when you want it, it’s super powerful.
- Payments are incredibly handy!
[Also: Agree with @mbaizman that the data importer is pretty cool. Actually cooler than most people realize and underutilized.]
What I would change?
- My gut says we might not need customizable rollups anymore. (We could probably do them with DLRS.)
- I’m not entirely convinced that Contact Point Email and Contact Point Phone are terribly useful. But at the same time, the multiple NPSP email fields also create confusion. We should put thought here.
- It would be really nice if there were some way to use the Household Account data model yet still be able to use things like the Outlook/Google plug-in without confusion.
- Does anyone use engagement plans or levels? Now that Flow is so much more powerful, at least some of the underlying automation may not be needed.
- I actually disagree about the Getting Started page. I just feel like it will always fall out of date, if you have a consultant implement they’re going to hide it from users, etc, etc. I appreciate the idea and the work @mbaizman, but I think in a world with few self-implementations it’s a bit redundant.
1 reply
My only reply to you @mkolodner is this: 
(but I understand what you’re saying, and I am too close to it to be unbiased)
cc: #30
I also love the data import tool and use it all of the time. I think it would actually be MORE important for an open source system like this one because without Salesforce leaning on ISVs they are not going to have the equivalent of an NPSP-flavored salesforce integration, which I think is super important for things like payment processing. If the data import tool is there its not too daunting to have an org use zapier or some other low-cost tool to dump donation data into import records and handle mapping without having to build a custom integration.
I agree with @mkolodner on what NPSP got right. I think that it’s critical that NPPatch play nicely with PMM, Volunteers, and the Outbound Funds module.
Although I was never a huge fan of Engagement Plans and Levels, many nonprofit orgs use them quite effectively.
One shift I’d like to see is standardizing the use of the name field to the name the constituent wants to use and be known by. Rather than the nickname field, I’d like to add a Legal Name field for a constituent’s government name, if needed.