Person Accounts - The Missing Map
Overview
In my experience as a consultant Person Accounts are one of most misunderstood and even feared aspects of the Salesforce platform. The way they work break conventions and often seem very complex.
The truth is it doesn't take long to get up to speed with Person Accounts. If you're already comfortable with data models, sharing and visibility, and general declarative programming person accounts are not something to worry about or avoid.
This is my missing manual to augment the official documentation.
What exactly is a Person Account?
A person account is a combination of the Account and Contact objects. When you create a PA record the platform is creating both standard objects and linking them together in the background. The key thing is that this is an attraction and you can treat the PA record like any other object.
Can PAs and "regular" Accounts coexist?
Yes, PA records can be identified with the following queries:
SELECT IsPersonAccount FROM Account SELECT IsPersonAccount FROM Account
What about custom fields?
Custom fields can be added to either object and it's best to approach this strategically. Should the custom field be placed on the Account or Contact?
Account
Ask yourself “Does the field need to be on both my PA and Business Account records?” If Yes put it here. In general these will be the fields that describe your relationship with the person (KYC).
Contact
Does the field fit on general contacts as well as PAs? Put it in contact. Contact fields describe the individual. I like to call these heartbeat fields. They include immutable attributes and would also apply to the person even if they were not your customer. Think of birthdate or veteran status as good candidates for PA fields that should go on the contact.
How do I access these fields? What's the deal with “__pc”?
Depending on where the field lives there is a required convention for querying fields for person accounts.
This table demonstrates the fields you would select in a query that pulls standard and custom fields from Account and Contact.
| Account | Contact | |
|---|---|---|
| Account | Name | Custom__c |
| Contact | PersonLastName | Custom__pc |
SELECT Name, PersonLastName, Custom__c, Custom__pc FROM Account
I'm getting errors that my field is inaccessible...
Because the field is referenced from two places there is actually Field Level Security in two places. These are not linked and it's possible you have read access on Account.PersonBirthdate but no access on Contact.Birthdate.
If you’re getting this message the FLS for both objects should be checked before going down any other paths.
What about Financial Services Cloud and "individuals"?
It's true that FSC has references to an "individual" model for people but that should not be used on new implementations. This model recreated person accounts through triggers and predated the full support of person accounts. It's possible to migrate from the individual model to person accounts and this will benefit performance as well as improve compatibility with other features.
What are the benefits if I still don't see the point of this overhead?
Person accounts actually reduce overhead. What is added in terms of managing additional layouts and record types is more than made up for with these additional benefits.
Single List Views - You can include fields from both the account and contact in a single view and can filter on both. For example you can build a listview of persons within a custom segment (account field) over a certain age (contact field).
Similarly the record detail page can show a mix of Account and Contact fields in a single view. This is especially nice on mobile.
Sharing only needs to be managed on the single record.
A single data job is all that's required for loading a person account.
Better performance because a single atomic operation is all that's needed to update the PA record.
