Understand the NPSP Data Model
After completing this unit, you’ll be able to:
- Describe the Salesforce data model.
- Summarize the basics of the NPSP data model.
Okay, maybe you didn’t come to this fortune via a cookie, but somewhere along the line it was decided that you would become the person responsible for the upkeep, configuration, and reliable operation of Salesforce for your nonprofit. You might be a full-time dedicated administrator (amazing!), you might be what we call an “also admin” as in “I will serve as the admin while I ALSO fill my other roles” (also amazing!), you might even be a part-time volunteer (this too is amazing!). No matter what your exact role, this trail provides a basic overview of how to set up the Nonprofit Success Pack - a tool for Salesforce designed specifically for nonprofits.
As we go, we’ll recommend places where you can dig deeper into Salesforce when you want to, but be warned: Salesforce is a powerful and complex suite of products and there will always be new things to learn. So don’t expect to “master Salesforce” in a couple hours or even a couple days.
Finally, we strongly recommend that you take the Fundraise with Nonprofit Cloud trail prior to this module. It explains a few concepts that we are going to assume you already know. If you plan on taking full advantage of Salesforce, we also recommend taking the Admin Beginner trail at some point too, so you have a solid understanding of ALL the Salesforce platform can do to help your organization work more effectively.
The “Sales” in Salesforce is a not-so-subtle clue that it started out as software for automating sales processes, and by extension, maximizing sales revenue. In fact, the product was originally designed for businesses selling to other businesses.
So, in Salesforce CRM, the account is a critical entity. Salespeople sell to individuals (contacts) who represent the account and influence the purchase decision. The sales pitches themselves (say 5000 units for $1) are known as opportunities. These too, are connected to the account. The way the data is tracked about that entity is called an account, and how the account data relates to and interacts with other important entities, like sales opportunities, is what is called the Salesforce data model.
A data model basically lays out how data is stored and linked in database tables. Most humans don’t think in terms of database tables (you’re extraordinary if you do) so let’s think about it like storing data in a spreadsheet.
In Salesforce, we think about spreadsheets as objects, we think about columns as fields, and rows as records. So instead of an account spreadsheet, we have an account object with fields and a bunch of identically structured records. The job of a data model is to make data easier to comprehend. This is how the data looks in Salesforce:
(1) An app in Salesforce is a set of objects, fields, and other functionality that supports a business process. The NPSP is an app. You can see which app you’re using and switch between apps using the app launcher ( ).
(2) Objects that exist in your Salesforce org. There are two kinds of objects: standard and custom. Standard Objects are automatically included with Salesforce and serve common needs for businesses, like account, contact, lead, and opportunity. Custom objects are objects that you create and tailor to your organization's specific needs.
(3) Records are the actual data associated with an object. Shown above is the record for all the data related to the Alvarez Family.
(4) Every standard and custom object has fields attached to it (which you can find within the Details section on a record). Each standard object comes with a set of prebuilt, standard fields. Additionally, NPSP comes with its own set of custom fields, custom objects, and automation. You can customize standard or NPSP custom objects further by adding additional custom fields.
(5) Related objects and records are all linked to each other in Salesforce. In Salesforce-speak, these “related lists” show you essential related data, all in one place.
NPSP is essentially a group of customizations to the base Salesforce platform. Accounts, contacts, and opportunities are still the major building blocks, but in nonprofit CRM, we care about managing constituent data and optimizing fundraising and program activities. We track a different set of entities and their relationships—namely, individual donors, their household affiliations, and donations.
In NPSP, for instance, accounts are used to represent households. Each household can be associated with multiple donors (contacts) and donations (opportunities). And since many nonprofits may need to track more than donors, they can use contacts to manage all kinds of people data — members, volunteers, clients, board members. And they can use opportunities to manage grants, in-kind gifts, and memberships — not just donations.
You may have seen this before, but let's review how NPSP uses the standard Salesforce objects.
||Donor or client households, companies, foundation funders, or other organizations with whom your organization has a relationship. There are two main types of accounts you can create in NPSP: Households and organizations. Household accounts are used
to track donor or member households. Organization accounts are used for any other accounts such as funders, corporate donors, vendors, government institutions, or other business entities.
||Individual stakeholders in your organization. All contacts must be connected to an account. The contacts object can be used to track donors, members, volunteers, clients and staff — basically any individual that interacts with your organization.
||Potential revenue-generating activities like donations, grants, or membership fees tracked over time, from pledge to received. These could include: financial contributions from a person or a company, grants from a funder, contracts from a government
institution, or sales of merchandise related to your organization.
||Any outreach you’d like to plan, manage, and track. Opportunities can be credited to a campaign (or multiple campaigns) to determine your return on investment.
The NPSP data model also includes objects custom to NPSP including affiliations, relationships, engagement plan templates, recurring donations, payments, and a few more. Okay, we know that you are just learning how to swim with NPSP, but we are going to throw you in the deep end, just for a second. We promise to yank you out just in time.
This is the NPSP data model:
You don’t need to spend time digging into this right now, but we wanted you to see an example of a data model diagram and get a sense of some of the standard and custom objects that are part of NPSP.
Now, as we’ve mentioned, you can customize Salesforce and NPSP even further by adding your own custom objects, fields, automations and so on. And when you do, you will be designing your own unique data model.
Your data model influences how you import data into Salesforce, and understanding it ensures records are created and related to each other properly. For example, if you’re importing contact information for a donor who’s donated to your organization for years, you want to make sure that the donation records you import relate correctly to that contact. There are countless examples like this that show how important data entity relationships are in Salesforce. But not only that — the data model also affects how you integrate with external systems, because each external system has its own data model that needs to be able to “talk” to yours. Incidentally, by using NPSP, you get the benefit of a tried-and-true data model that’s compatible with other commonly-used nonprofit apps.
When you start to plan out how you’ll use Salesforce, it’s critical that your data model includes all the things that uniquely represent your nonprofit’s activities — donors and members, donations, grants, events, donations of goods and services, client caseloads, and advocacy campaigns. It’s equally critical to define the relationships between them — to associate donated materials to their donor contacts and to their recipient contacts, client contacts to cases and staff members, and so on.
This is where planning becomes crucial.
The entity relationship diagram (ERD) below was created by a tool called the Salesforce schema builder and illustrates a portion of a well thought-out data model. Each box represents an entity, and the lines show relationships between the entities. Schema builder is a tool that lets you visualize and edit your data model. It’s useful for designing and understanding complex data models.
Salesforce is a flexible system, but the design of your data model is one of the few decisions you have to make that gets set in stone, so to speak. Your data model becomes the foundation for your entire system and making big changes to that foundation later is disruptive and potentially expensive.
Now that we understand a little bit about the basics of the Salesforce platform, let’s take a minute to set some realistic expectations about what it will take to be successful in your implementation and adoption of Salesforce.