- Published on
Businesses, Households, Person Accounts and Individuals - Which Should You Use?
- Authors
- Name
- Emily McCowan
- @heyemilyhay
Updated 1 June 2021: Since publishing this article, I learned about the Account Relationship object, so I've added that to the "How do I relate Business Accounts & Contacts, and Person Accounts?" section. #AlwaysLearning :)
Salesforce has a number of objects and data models designed to support multiple use cases for tracking information about businesses and people. It can get a little confusing - when should I use Person Accounts vs. Household Accounts with Contacts? How does the Individual object fit into this? What do I do if I have Person Accounts and Business Accounts with Contacts in the same org? Can I change my mind later? Everyone keeps saying Person Accounts sucks and I should steer clear, is it really that bad?
Well, hopefully I can help you answer these questions today! Note - for this post I'm going to ignore Leads, just considering the different methods for storing qualified B2B and B2C data.
Person Account
A B2C data model. Person Accounts store information about individual people by combining certain Account and Contact fields into a single record.
Basically, if you sell to or otherwise work with individuals, Person Accounts may be the data model for you. You can provision external users set up as Person Accounts with Customer Community & Customer Community Plus licenses, but not Partner Community licenses.
Person Accounts are highly unpopular on the internet, but since when was the internet right about anything? Seriously though, Person Accounts can be really good but you need to know how to implement them and be ready for some quirks.
Ultimately, we architects don’t design Salesforce orgs for the joy of the developers that implement them - sorry (not sorry). If Person Accounts are going to work better for the end users and the organisation using Salesforce, then don’t be afraid to use them!
The Person Account Data Model
Business Account & Contact
The B2B data model. The original framework for Salesforce, you would use Accounts to track the companies you sell to and work with, and Contacts to track their employees.
If you’re enabling a Partner Experience via Experience Cloud, your external partners must be set up in an Account & Contact data model in order to be provisioned with Partner Community licenses (i.e., Person Accounts are incompatible with Partner Community licenses).
The Business Account & Contact Data Model
Household Account & Contact
Household Account & Contact is interesting, because in structure it’s identical to the Business Account & Contact model, but it's for B2C use cases. It’s generally used by nonprofits like charitable organisations, or educational institutions.
This data model is a key aspect of the Salesforce EDA and NPSP data models and centralises the view of people and their relationships. Salesforce has some more information on how best to leverage the Household Account & Contact data model here.
The Household Account & Contact Data Model (hey… that looks familiar...)
Private / Orphaned Contacts
Salesforce lets you create Contacts without a parent Account - these are called Private or Orphaned Contacts. You have to enable your users to set up Private Contacts by removing the Required flag from the Account lookup field on the Contact page layout.
Private Contacts have their uses - e.g. in an org that is not using Leads, Pardot can sync new… well… "leads-that-aren't-Leads" into the Contact object. It’s important to remember that any Private Contacts are just that - they are not visible to anyone besides the owner and the System Administrator. Always. Fair to say it’d be hard to get a 360 degree view of customers using this model. Like I said, it has it's uses, but keep it in your back pocket for edge cases - please don't use it as the norm.
The Private Contact Data Model (lol, I had to)
Individual
There are two different types of “Individual” you might come across in the world of Salesforce. They are the Individual OBJECT, and the Individual DATA MODEL.
The Individual Object
The Individual object was introduced in Spring ‘18 and allows companies using Salesforce to track data privacy and protection preferences. It was created in response to the growing number of countries around the world introducing legislation aimed at supporting individuals’ rights to control what companies can do with their personal information, like GDPR.
The Individual object is NOT meant to replace your Account/Contact data model - instead, you can relate your Account, Contact, Person Account, and other records like Lead and Community User to the matching Individual record. Salesforce has an overview of their Privacy products here, which includes links to trails for the EU, US and CCPA.
An Example of The Individual Object Related to Account & Contact
The Individual Data Model - Financial Services Cloud & Health Cloud
Financial Services Cloud and Health Cloud have provided the Individual record type on Accounts and Contacts to represent individuals.
The Individual Data Model (You again!)
Salesforce are deprecating the Individual data model. No new Health Cloud or Financial Services Cloud customers will be able to set up the Individual data model, and they recommend existing customers undertake migrating from the Individual data model to the Person Account data model.
Salesforce has guides for migrating from the Individual data model to Person Accounts for Health Cloud here, and for Financial Services Cloud here.
So which data model(s) should you use?
It depends, of course, on your company’s use cases, as well as the Salesforce and AppExchange products you’re using. The table below shows a few basic example use cases and what options are open to you.
If you’re using products like EDA or NPSP, you’ll likely be using the Household Account & Contact data model. If you’re using Salesforce Industries (FKA Vlocity), you may be required to use Person Accounts (e.g. for Salesforce Public Sector Solutions). There may be AppExchange products you’ve installed that are incompatible with Person Accounts. These are all things to consider when you’re selecting the right data model for your org.
Person Account | Business Account & Contact | Household Account & Contact | Private Contacts | Individual Account & Contact* | |
---|---|---|---|---|---|
B2B | No | Yes | No | It's | No |
Partners | No | Yes | No | Really | No |
Customers | Yes | No | Yes | Not | Yes |
Donors | Yes | No | Yes | A | Yes |
Students | Yes | No | Yes | Good | Yes |
Patients | Yes | No | Yes | Idea! | Yes |
It’s also possible that you may opt for one data model, and realise in time that you need to migrate to another. You're not necessarily locked into forever using the first data model you choose, but the more mature your org the more complex a migration will be, and you may eventually reach a point of diminishing returns versus migrating to a new org entirely, or adopting a multi org strategy.
Can I use more than one of the data models?
You may need to store information about businesses and employees, as well as your partners, as well as individual people in Salesforce. Some of the data models provided are compatible and some aren’t, so I’ve put together a compatibility matrix to help clarify this.
Person Account | Business Account & Contact | Household Account & Contact | Private Contacts | Individual Account & Contact | |
---|---|---|---|---|---|
Person Account | - | Yes | No | Yes | No |
Business Account & Contact | Yes | - | Yes | Yes | Yes |
Household Account & Contact | No | Yes | - | Yes | No |
Private Contacts | Yes | Yes | Yes | - | Yes |
Individual Account & Contact | No | Yes | No | Yes | - |
Note that it might be possible to have multiple of these data models in the same org but it is not always recommended - basically, don’t mix your B2C models. Untangling whether a customer should be represented via the Household & Contact model vs Person Account model if you have both will be unnecessarily difficult for your users - keep it simple!
How do I relate Business Accounts & Contacts, and Person Accounts?
Say, for example, you have decided you’re opting for Business Accounts & Contacts along with Person Accounts. Great!
As you’re setting up your data, you come across this scenario. You’ve got a partner company - let’s call them Octo Inc. One of their employees, Eric, has been set up with a login to your partner community via his Contact record.
But now you’re looking at your customer data, and you realise Eric has also been purchasing products from you directly for his own personal use. You need to keep information about Eric in his Person Account record, too.
Here’s one way to visualise this scenario, but...
I prefer this visualisation, myself.
To relate Business Accounts & Contacts to Person Accounts, you have a couple of options:
- Account Contact Relationship
- Account Relationship
Account Contact Relationship
The Account Contact Relationship object is a standard object. It’s not only useful for relating one Contact to many Accounts in the B2B world, you can use it to relate Person Accounts to Contacts, as well as Person Accounts to Business Accounts, and indeed Person Accounts to other Person Accounts. It's useful in this scenario where you have a deliberate duplication of a person via a Person Account and a Contact record. Note: The Individual object will also come in handy here to keep track of your "golden individual".
Account Contact Relationship: pretty useful.
Account Relationship
You can switch on the Account Relationship feature, which will add a new object to your schema and enable the relating of Person Accounts to other Person Accounts, as well as Person Accounts to Business Accounts (if ACR mentioned above doesn't fit your use case). It serves as a junction object between Accounts, creating a many-to-many relationship. It also comes with some pretty neat sharing features that are useful in Experience Cloud, you can learn more from Salesforce here.
Summary
While Salesforce have just one data model for B2B Accounts & Contacts, they provide a number of models for storing B2C data. Which one you pick will depend on your use cases, and products you’re currently using and plan to use in the near future. It’s always possible to change the data model you’re using - however that’s not necessarily a simple exercise.
If you have any questions, or comments, please reach out to me on Twitter @heyemilyhay.