I’ve seen this topic come up quite a bit online, and I think it’s time we shed some light.
If you’re new to Salesforce and work in this sector, then you’ve likely heard about the Nonprofit Success Pack (also known as NPSP). Either your org is already on it, or you’ve heard peers/consultants toss the term around.
But what exactly is NPSP, and how does (or doesn’t it) relate to Salesforce?
The difference explained.
Here’s what’s true. Every organization that uses NPSP also uses Salesforce. You can’t have the former without the latter.
But NPSP is an optional add-on. So not every nonprofit that uses Salesforce has to necessarily use NPSP. (Although, don’t get me wrong…the vast majority do!)
In short, think of Salesforce as an iPhone and NPSP as the app. A very big app.
Now that we’ve cleared that up….
Now that we’re on the same page, let’s expand on this some more! Here are 5 basic things to understand when you’re talking about NPSP and Salesforce for your org.
1. You can check for duplicates in Salesforce, regardless of NPSP.
It takes some familiarizing, but admins can handle duplicates using functionality already baked into the Salesforce setup! Think duplicate record sets that generate reports (my method), duplicate jobs based on matching rules, and Contact merging.
So if you’re worried that having NPSP means you don’t have these capabilities, no worries! You can find these things within setup. (And if none of those options are enough, you can always purchase de-duping tools on the AppExchange.)
2. Getting NPSP is as easy as going to the AppExchange.
That online store I linked to above? That’s the same place where you’d install NPSP. You can also do it from the Power of Us Hub, an online community specifically for nonprofit Salesforce customers. There you’ll find instructions for installation, common errors, and important considerations (assuming you’re doing this without a partner).
3. You can always tell which components were installed by NPSP.
NPSP is a group of managed packages – basically sets of fields/objects/rules that get added to your Salesforce instance once installed. These components are created & maintained by the package creators (in this case, Salesforce.org). This means that as an admin, you won’t be able to edit/delete certain things.
This is less important when your org is new. But as you create custom objects/fields, you’ll want to distinguish those package components from your own. You can do this by visiting the Installed Packages section within Setup > clicking on the package > and clicking View Components.
4. NPSP comes with reports, but it’s much better to create your own.
Reports are the bread and butter of your Salesforce efforts, a dynamic way of understanding and double-checking the data that goes into your system. NPSP comes with a set of pre-built reports, to help get you up and running with the data that matters.
But in order to get the most from Salesforce, you’ll want to learn how to create your own reports. Not only are reports totally learn-able, but knowing how to build them gives you much more flexibility when you get a super specific request, or need to report on new objects/fields.
5. “Classic” and “Lightning” have nothing to do with NPSP.
You’ll learn what this means once you’ve actually implemented Salesforce. But until then, know that Classic and Lightning refer to two different user interfaces – with the latter being the newer, preferred version.
pssst! If you’re new to the Salesforce ecosystem, check out my top favorite resources for nonprofit admins.