For years Person Accounts were a bit of a joke in the Salesforce community, something people liked to trot out as a feature you should avoid like the plague because this or that commonly-used feature would break if you enabled them. But at the same time, people would note that if you are architecting an instance that is literally only meant to work with people as individuals (not connected to “accounts” or “households” or the like) then person accounts are the official solution.
So you can imagine the range of reactions when Salesforce.org let it be known that the new clouds would be based on person accounts. Besides this being a huge shift from the Household Account model of NPSP, there were a lot of people wondering what would happen if they suddenly have to use this feature that’s the butt of so many jokes.
On the other hand, Financial Services Cloud has apparently been using person accounts for years, so I assume Salesforce.org figured if it was good enough for banks and wealth managers, it would work for nonprofits. Despite all my feelings about the new clouds, that actually seemed reasonable to me.
But now I’m not so sure. I’ve had a couple of months to work in a real implementation of Education Cloud and poke around a new Nonprofit Cloud (NPC) trial and I’m starting to see that person accounts are a benefit and a curse.
The Benefit
OK, let’s start with the positive. By making every contact an account in their own right it seems like things are simpler in those instances where you mostly are concerned about someone as a person. If you aren’t concerned about who the other people in their household are, you don’t have the unnecessary creation of a household account, like you do in NPSP or EDA. That account never really bothered me (the NPSP triggers take care of creating it), but I know that some people found it confusing or annoying. (Some people also complained that the extra account could potentially impact storage usage or report speeds. Person accounts don’t solve either of these issues, though, because every person is both a contact and an account, so you might actually have more, not fewer, accounts in your org.)
I actually worked on an implementation several years ago for a small law firm where I chose to use person accounts because each of their clients really was essentially a separate "account." For me it was a bit of a perspective shift not having a Contacts tab visible and having to choose Account>New when entering a new person. But that’s because I have longstanding habits. For the firm’s users it was all they knew of Salesforce and I don’t think they ever even considered it strange.
The Curse
The problem with person accounts, however, comes when you start trying to have relationships between people or between people and business/organization accounts. I know Financial Services Cloud works with exactly these data points, particularly for wealth management, using the same Industries objects that the new clouds use. Maybe in that industry the terminology is less of a barrier? But for those of us used to working with nonprofits, particularly used to doing so in Salesforce, the whole thing is just so much less understandable than NPSP.
In NPSP there are three things we track:
Relationships, which are between two people. (Example: Buffy’s mother is Joyce.) In most cases relationships should doubled, so we can understand the reciprocal relationship. (Joyce’s daughter is Buffy.)
Affiliations, which are between a person and an organization. (Example: Buffy goes to Sunnydale High School.) These often have start and end dates, since people may change jobs, graduate from school, or come and go as volunteers for an organization.
Households, which group people. (Example: The Summers Household: Joyce, Buffy, and Dawn.)
Each of those NPSP objects is named exactly how we use it. When training users about these I never really have to explain more than the bullet points above. People just “get it.”
In the person account model of the new clouds just the naming of relationships makes me want to cry:
Contact Contact Relationships (CCRs) are between two people.
Account Contact Relationships (ACRs) are between a person and a business account.
Account Account Relationships (AARs) are between two business accounts.
First of all, they’re all “relationships,” so it’s hard to distinguish. Second, saying or writing those object names is awful. So of course people are going to use abbreviations. But abbreviations just make things harder for new people to understand. I try to avoid abbreviations and jargon as much as I can. But I’d go bonkers saying and writing these out all the time!
And it’s not like the full names really help to convey information. If you’re talking to a user that's new to Salesforce and is on person accounts, they basically never hear the word "contact" in a Salesforce context. All they create and work with are "accounts." Yet you’ll tell them they’re creating a "contact contact relationship." Are you kidding me? Also, given that these two people are both person accounts, why wouldn’t this just be an AAR (account account relationship)? I don't know. But you can't use AARs for that.
I’ve been studying and working with this stuff for months and I still have trouble remembering what's what. If you want to group people into a household, that’s going to be some ACRs. Not clear on why they aren’t AARs, given each person in the household is an account and the household is also an account. But that's not how households are done.
It gets worse.
For some technical reason that I don’t understand, you can’t work with these things the way you'd expect in list views. (I really don’t understand all the moving parts here yet.) Not that I particularly want to put three list views on the page layout labeled Contact Contact Relationships, Account Contact Relationships, and Account Account Relationships. That would surely be a challenge for users (see above). But I definitely do want to put lists of relationships and of what-I-would-prefer-to-call-"affiliations" on the page.
I think it might work to put related lists on the page. But Salesforce insists the right way is to use the "Actionable Relationship Center." I can’t remember why, but I recall some limitation around the related lists that is apparently insurmountable.
Actionable Relationship Center (ARC)
Salesforce is convinced this thing is super neat because it can display relationships in a hierarchical tree view and can group all three kinds of relationships together and can even show other objects once you configure it. OK, that’s interesting as a tool I might pull up to browse information about a donor or client.
But if I want to quickly see that Joyce has two daughters when I go to her record, I want a list, not some kind of graphical tree. If I want to see that Buffy’s mom is Joyce and her sister is Dawn, I want a list. If I want to look at Buffy’s history of education and employment, I want a list. Lists are information dense, easy to sort (say, by start date) and re-sort, and nearly instant to comprehend. Also, if I’m looking for someone's relationships, I'm probably going to take in relationships to people very differently than I'm going to take in relationships to organizations. So they should be in separate places. Compare that to what you see in the ARC. 🤔
Also, when you want to actually take action with the actionable relationship center, such as creating a new relationship, you have to click the carat before you can click Add Relationship. Some people will never find that. (And it’s two clicks instead of one for everyone else.) Sure, in that image above, I can create a new Gift Commitment right in the ARC. But when I build my page layout for a gift officer, I'd make sure they could create a Gift Commitment quickly from a related list or a button, so color me unimpressed.
By the way, I had to figure out how to configure the “Relationship Graph” to even show Contact Contact Relationships in the first place. The NPSP trial org has ARCs in it, but they are only configured to show Account Contact Relationships. 🤯
(See my prior post on why implementing and maintaining the new clouds is so much more expensive.)
This Isn’t About Fundraising
None of this post has anything to do with fundraising. These are the hassles of managing people and their relationships in the new clouds, regardless of what you are going to do. Many of my current clients don’t really do sophisticated fundraising (or don't do it on Salesforce...yet). I've built them custom program management solutions on top of NPSP because the relationship/affiliation management features are a great complement to the rest of the architecture we need.
But if I were to try to build a similar architecture of custom program management for these clients on the new clouds I would also have to work around all these annoying ways that the relationships aren’t helping.
Bottom Line
Feels like a dodge to end this way, but the title says it all: I'm still skeptical of person accounts. I might end up using them, particularly if they become The Way of the Future. But so far, I'm not yet convinced.