Translate Your Nonprofit Data to Salesforce
- Explain why a data model matters.
- Explain how Salesforce objects store data in records, fields, and field values.
- Describe the features that come automatically with Salesforce objects.
- Explain what a standard object is.
We’ve already compared the accounts and contacts of the sales world to the households and donors of the nonprofit world. What we’ve really been talking about, even though we haven’t called it by name yet, is the Salesforce data model. You may also hear it referred to as the account model (or household account model in the NPSP context) or object model, but they’re all the same thing. Please bear with us—we get a bit technical here.
In NPSP, the household is a really important entity, or thing. The data model determines what data we track about that thing, and how the data relates to and interacts with other important things, like donor data and donation data.
As a refresher, here’s that visual representation of the simple data model we showed you before. It’s worth looking at again, now that you know it’s a data model!
Your data model also influences how you import data into Salesforce, so that 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 the NPSP version of Salesforce, you get the benefit of a tried-and-true data model that’s compatible with other commonly used industry products.)
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, material (rather than cash) donations, client caseloads, 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 illustrates part of a well-thought-out data model. Each box represents an entity, and the lines show relationships between the entities. Creating an ERD is a useful exercise when planning your implementation. It helps you account for all of your entities and figure out which ones need to relate to each other, and how.
Salesforce is a flexible system, but your data model design is one of the only decisions you have to make that gets set in stone, so to speak. Your data model becomes the foundation for your entire system. Technically, you could rip out and redo part of the house foundation after you’ve poured it, but that sure is time—and labor—intensive! Best to consider carefully what you need, well before the cement truck shows up on site.
Thanks for sticking with us through all of that. The data model is one of the more abstract concepts that we all have to understand in Salesforce.
As we just learned, the NPSP data model is tailored for nonprofits, centered on the Account object. Notice that we call the Account an object. (Same for the Contact and Opportunity objects.)
An object in Salesforce is like a data table in a relational database. Or, as we often see in nonprofits, workbooks with data in various spreadsheets.
You can think of each row in a spreadsheet as a record in an object, representing a single household, a person, or a donation.
The columns in a spreadsheet are like fields within an object, representing one detail about a record, such as a name, an amount, a date, or a payment method. The number or text inside a spreadsheet cell is like the value of a field.
Here’s a picture of how all these terms and concepts come together, and how they map from the spreadsheet experience to the same experience in Salesforce:
While Salesforce objects are similar to database tables, they come with extra features that make data management easier. We won’t go into detail about every single benefit. Just know that the way Salesforce stores data automatically takes care of things that in other systems might require setup, configuration, or even specialized code. In this section, we talk about how things like the Salesforce user interface and Salesforce related records make managing your nonprofit data much easier. No more manual record keeping, and a lot fewer sticky notes!
- User Interface
- Salesforce provides a user interface that presents data about objects. Each tab that you see
in the header when you’re logged in to Salesforce represents an object—an account, a contact,
and so on.
And when you drill down into each object, you see the fields that come out-of-the-box.
- Related Objects and Records
- Related objects and records are all linked to each other in Salesforce. For example, a
household is usually related to multiple contact records, which represent members of the
household. And contacts’ various affiliations with workplaces, volunteer jobs, or other
organizations are all just a click away. In Salesforce-speak, these related lists
show you essential related data, all in one place.
- A flexible security model lets you control who has access to objects, records, and fields, because not all users need to see every detail about your donors. You can define security at whatever level makes sense for your nonprofit.
- You may be pleasantly surprised by how easy it is to run reports on your data in Salesforce. Use analytics to discover opportunities and anticipate problems before they surface. And create dashboards to visualize critical metrics.
- Mobile Access
- Run your nonprofit from your phone. Whether you’re a volunteer coordinator or the executive director at a nonprofit, you can access Salesforce from wherever you are, using the Salesforce app.
As you can see, Salesforce objects offer some really useful and time-saving benefits.
Salesforce and the Nonprofit Success Pack come with standard objects that are already set up and ready to use, much like a move-in ready house with a set of rooms that are already painted and furnished. For example, the Contact object comes with the fields you’d expect for tracking personal information, contact information, contact preferences, and so on. And with NPSP, you also get fields for tracking donor information.
In reality, though, every nonprofit is unique. The standard layout and finishes of your “house” usually aren’t exactly what you would’ve selected. You want to make changes, to make the place feel more like your own. Some changes are easy—like swapping out a shower curtain. Other changes involve more work. For example, your growing family might really need two bathrooms instead of the single bathroom that comes with the standard design. If you don’t plan for that second bathroom as you’re laying your foundation, you’ll have to add it after the home’s already built. Now we’re talking more expensive extra structural supports, accounting for additional plumbing and drainage, and so on.
What we’re getting at is the importance of customization. Now that you know what Salesforce standard objects are and how they store your data, it’s time to start thinking about how you might want to customize them, or even create your own custom objects, to meet the needs of your own nonprofit.