For whatever reason, the concept of Person Accounts gives some admins a cold shiver.  The implications of enabling person accounts tend to make Person Account migration a “future” project that just gets kicked down the road.  The purpose of this article is to walk through a process for deciding if your organization should use Person Accounts and discuss how to make sure the move goes smoothly.

Person Accounts in Salesforce

1. Evaluate the Person Account use case

Should I use Person Accounts?

Simply stated . . . If your customer base – or a sub-segment of your customer base – are individual consumers, Person Accounts are a good idea.  Person Accounts combine the attributes of both Accounts and Contacts into a single object.  This saves quite a bit of time for manual creation as well as processing time for the system.  Furthermore, it creates consistency in naming and relationship between these two standard objects, keeping the system clean and eliminating a potential chance for error.  While mismatching Accounts and Contacts or misnaming them is not a huge weak spot for most orgs, it is a good practice to tighten up the system at every opportunity.

Part of the brilliance of Salesforce is that fact that it is simultaneously intuitive and extremely useful out-of-the-box while being fully customizable in a myriad of ways.  Salesforce provides an ever-growing array of native functionality, and these features work best when using the core standard objects (Leads, Accounts, Contacts, Opportunities, Cases, etc).  While customers can be managed as Contacts without Accounts, things better utilize these features when the Account object is used, especially as a bridge between Contacts and Opportunities.  The Person Account serves as an Account and Contact simultaneously, giving the ability to report and automate on either object.  All of this while only requiring a single object to be created and maintained.

Should I use Person Accounts if some of my Accounts are businesses?

In this case, make use of record types on the Account object.  Create a standard account record type for the business accounts.  This would not be a Person Account record type.  Then create a second record type for the individuals (B2C customers, individuals who are not associated with a company in relation to your org).  Person Accounts will still need to be enabled – which cannot be undone – but this will allow you to mix traditional Accounts with Person Accounts in the same organization.

2. Enabling Person Accounts

Person Accounts are actually enabled by Salesforce Customer Support.  There are a few prerequisites before enabling, but once those have been met, select Allow Customer Support to enable Person Accounts.  Follow this up by logging a case with Salesforce Customer Support to actually get Person Accounts turned on.  You will receive an email with instruction for what information to provide in the case.

When you first plan to turn on Person Accounts, make sure that there is at least one record type existing for the Account object.  Once Person Accounts are enabled, it will create a Person Account record type as well.  You will still be able to create regular Account record types and additional Person Account record types.  Page layouts for Person Accounts can actually be edited on a separate object, although the fields will managed on the Account object.

Since the Person Account is essentially an Account record and Contact record, we also need to look at security on the objects.   In the standard object hierarchy, the Contact is a child to an Account.  So for security purposes, we either need the organization-wide sharing setting for Contacts to be Controlled by Parent, or both Accounts and Contacts need to be Private.

3. Additional Considerations – features that are the same

For the most part, Person Accounts behave the same way as Accounts and Contacts respectively behave.  Here are some features that you can expect to operate the same way:

Activities – normal 

Approval Processes – except use the First Name and Last Name (like a contact) instead of Account Name

Assets – normal 

Campaigns – except the visibility of a contact object-based related list

Cases – normal 

Custom Object Relationships – normal 

Email Integration – normal 

Events – normal 

Fields – all of the normal Account and Contact fields except those that would be excluded due to lack of hierarchy for Person Accounts, such as the Parent Account field or the Reports To field

Field History – normal 

List Views – normal for both Accounts and Contacts except “Recently Viewed Contacts” lists

Opportunity Contact Roles – normal using Contact Roles

Partners – normal

Process Builder – normal

Sales Dialer - normal

Search – normal

Social Accounts – normal

Storage – normal (still counts as an Account and a Contact)

Workflow Rules – normal 

4. Additional Considerations – features that are different

Account Relationships – Unlike traditional Accounts, Person Accounts can’t be part of a hierarchy or have a direct relationship with other accounts (the way a regular contact would).  The Contacts with Multiple Accounts feature can indirectly relate a Person Account to another Person Account or regular Account.  However, if this is regularly the case, then this would not really be the use case for using Person Accounts in the first place.  

Chatter Feed Tracking – following a Person Account record will follow the Account Fields but not the Contact

Contact Relationships – like the Account relationships above, the Contacts with Multiple Accounts can indirectly link a Person Account to another Contact.

Email – individual and group emails with Person Accounts will work the same.  However, list view emails will go from the Contact object list view rather than Account list views.

Experience Cloud Sites and Portals – while Person Accounts can be enabled for users for customer Experience Cloud sites and portals, they cannot be enabled for partner Experience Cloud sites and portals.  

Formula Fields – custom formula fields on Contacts won’t inherently work on the Contact portion of a Person Account.

Lead Conversion – this is an important consideration for enabling Person Accounts.  By default, leads without the Company field populated will convert to Person Accounts while those with a company will go to traditional business Accounts

Marketing Cloud and Pardot – additional configuration is required that is beyond the scope of this article

Page Layouts – as stated earlier, Person Accounts will have their own page layouts.  A Person Account page layout must be assigned to a Person Account record type.  When setting up a page layout, all of the account fields will be available except those that aren’t available specifically for Person Accounts (i.e. Parent Account, Reports To, etc).

Self-Registering Pages – as an admin, you will dictate whether they come in as Person Accounts or Contacts on Business Accounts

Tabs and Standard Fields – tabs can be renamed on Person Accounts, as well as standard fields.  Changes will need to be made on both the Account and Contact tabs and/or fields.  

5. Converting and Merging to Person Account

For new organizations or those adding a new business segment that warrants enabling Person Accounts, conversing from a Business Account won’t be a necessary step.  On the other hand, if a company makes a decision to start using Person Accounts for existing B2C-type customers, it is good to know how to update the records.  Record types need to be updated through an API.  Use apps like Data Loader or Workbench to mass update records.  To make the conversion, export the desired records to Excel with all fields.  Add a column for the new Person Account record type, grab the 18-digit code for all values in that column, and then save.  Then upload the list back into Salesforce via the API and correlate the record type column to the account record type in the field mapping.  This will convert the accounts to Person Accounts.  The same process can be completed to move Person Accounts to Business Accounts.

When it comes to merging, Person Accounts can only be merged with other Person Accounts.  Likewise, Business Account merge with other Business Accounts.  As with any merge, one (or more) records is deleted from the system and the remaining record will inherit the related records (i.e. cases, tasks, etc).  Person Accounts that are Portal or Experience Cloud site users cannot be merged.

‍