MLP for Bridge

Last post I wrote about Nonprofit Bridge. While I have a lot of opinions about it, I'm trying very hard to let this be a project with input from multiple voices. But I can't help myself; I'm already thinking about features. I don't like the idea of a minimum viable product, that threshold seems too low. But what would be the minimum lovable product?

First of all, I have no idea if Bridge is going to eventually involve an installable “package” (locked, unlocked, managed, unmanaged, ...?), or merely a GitHub repo of metadata with instructions how you can get that metadata into your org, or something else entirely, People much smarter than I, with better understanding of the pros and cons for various ways of "publishing" or "releasing," will need to discuss. It occurs to me that it's not even clear if the final product should be a simple Open Source Commons project or if we’re going to have to create an independent nonprofit to own intellectual property held in common trust. There is a lot to be considered.

But despite all that uncertainty, I think I can articulate a baseline of features that I think small nonprofits need.

Individuals

Given its roots as a sales tool, with the required dependency of a Contact (and an Opportunity) to an Account, Salesforce “out of the box” does not work for most nonprofits and educational institutions. In the overwhelming majority of cases, those organizations need to manage people as individuals.

So the first thing I expect Bridge to provide is a way to do that.

The Household Account Breakthrough

In 2008 the community first came together to solve that problem. The Nonprofit Starter Pack, which became the Nonprofit Success Pack (NPSP), began life as an open source project to help nonprofits that wanted to take advantage of Salesforce’s generous product donation. Essentially, they had to answer, “How can we track people as people in this software clearly designed for a business-to-business (B2B) use case in which people (contacts) are tracked mainly due to where they work (accounts)?”

The eventual breakthrough that made NPSP so successful, in my opinion, was the creation of the Household Account Model. By automatically creating an account for each contact, to represent their household, NPSP made it possible to track donations (opportunities) and know that money came from an individual, not a company.

Putting people together in a household allowed us to understand that the donation (regardless of who physically forked over the cash) came from the household if we need to know that. But if we don't actually care about households, just people, the "Household Account Model" works just fine as the "Individual Account Model." Change the name of the account record type, never put two people in an account together, change the naming convention for [household] accounts, bury the Account field on the contact layout, and you've got a perfectly viable system for tracking people as people. Some people get fussy about the double data usage of potentially having an account for each contact. But personally I don't think that's such a big deal. (And Person Accounts has the same problem.)

Affiliations

Nonprofits also want to track how contacts are related to organizations, including where they work, other organizations they may support, and the like. In fact, in my experience nonprofits very much appreciate being able to track a history here, rather than just (as the standard Salesforce model has) where someone works right now.

NPSP's model of Organization Affiliations and the Primary Affiliation kept the option of tracking where people worked, if we needed to know that, plus any other involvement those people have with any other organizations (including our own). And through that kind of information, we could also see when donations were related to things like employer matching, influence in a foundation, etc.

Relationships

If you’re trying to understand people, you also care about relationships (spouses, parents, etc.) In my experience, actual usage here can vary widely and most organizations seem to just track a few key data points (like spouses, or guardians of enrolled children). But the NPSP Relationship object is simple and flexible, and the triggers to manage reciprocal relationships are very handy.

Fundraising

Here, actually, I’m not sure there is a lot of "functionality" need. If you look at what the Nonprofit Success Pack actually does around a fundraising data model, it’s not much: The package includes a Payment object, child to Opportunity, so you can have multiple payments on a gift. There are several opportunity record types. And NPSP also includes a lot of rollups about gifts, but I don’t consider those core as a functionality need because I think they’re no longer that hard to build with other tools. (Like DLRS.)

So while clearly nonprofits will need some features around fundraising, it may be surprising to notice that this might not be the most important area.

Could This Be Standard Functionality or “Core”?

Theoretically, the majority of the MLP that I've just outlined can be provided by Salesforce through out-of-the-box features in 2025, in a way it was not in 2008, when the NPSP was first published.

Standard Feature for Individuals and Relationships

Person Accounts are the official Salesforce method for managing individuals in a “B2C” (Business to Consumer) data model. Long a sad joke within the Salesforce world, the official company line is that they’re good now and they’re the basis for a lot of Industry cloud solutions, including Financial Services Cloud for wealth managers dealing with their clients.

I already wrote, in March 2024, that I haven’t managed to love Person Accounts. Re-read that post for my full review. But spoiler alert: I think they’re terrible. [I’m still open to having my mind changed, either that Person Accounts aren’t that bad or that it would be easier to hide the complexity from users than to do something else. But my current opinion is that we need something better than Person Accounts.]

Affiliations in the Sales Cloud Data Model

Similarly, you can enable the feature “Contacts to Multiple Accounts,” which enables a history of contacts’ relationships to accounts as they are edited. But the functionality you gain here is woefully underpowered compared to what NPSP does with Affiliations and the automation around Primary Affiliation. Could Contacts to Multiple Accounts be enhanced with some more fields and some more automation through Flow? Sure. But if you’re customizing like that, I see little benefit to using this standard Account History object rather than a fully realized custom object.

So yes, standard Salesforce features compete with the MLP that I'm advocating for Bridge. But they are complicated, confusing, and don't work well. They're not a good fit for small nonprofits with limited technical support resources.