Published on

Tips for Implementing Person Accounts in an Existing Salesforce Org

Authors
Article
Photo by Gauravdeep Singh Bansal on Unsplash

You’ve got an existing Salesforce org, and you’re looking at switching on Person Account. There is a whole lot that would go into making this decision, so for the sake of this post I'm going to assume you already know it needs to happen and you're looking for guidance on how to do this without breaking your existing configuration or upsetting your current users.

Salesforce has a Person Account implementation guide here (warning: links directly to PDF). I’m going to reference this guide a few times in this post so I recommend giving this a quick read before continuing. And so I don’t have to repeat “The Salesforce Person Account Implementation Guide” each time I reference it, I’m going to call it “the guide” from here on in.

The guide (as at the Summer ‘21 release) steps you through:

  • Person Account concepts & considerations
  • Preparing your org for Person Accounts
  • How to enable Person Accounts
  • Some recommended configurations for Person Accounts
  • Testing your Person Account setup
  • Importing data into Person Accounts
  • Converting Business Accounts to Person Accounts

While this is useful, I think it is missing some important information, so here are my tips to supplement the guide.

Data Schema

A Person Account isn’t really a separate object - it’s an Account and Contact stitched together. There can be some quirky behaviour of Person Accounts due to this mashing together of separate objects.

Your data schema will change when you switch on Person Accounts - most notably, an automatic copy of custom fields from the Contact object to the Account object. Identify these new fields by checking for the __pc suffix.

Data Migration

As per the guide, you can transform your Business Accounts to Person Accounts by changing the record type and with some data preparation, but what the guide doesn’t mention is the impact on Chatter feeds. When converting a Business Account & Contact to a Person Account record, you’ll retain the Account Chatter feed but you will lose your Contact Chatter feed.

You can get around this by backing up the Chatter feed data related to your Contacts, performing the conversion, and uploading the Chatter feed to the Person Account (with some tweaking). Salesforce has a how-to here on migrating the Chatter feed from one record to another while retaining original Created By and Created Date values.

Record Types

Once you’ve switched on the Person Account feature, you’ll automatically get one OOTB Person Account record type which has the IsPersonAccount value set to true. You can’t update an existing record type to set it as an IsPersonAccount type - you must use this new record type, or create a new one from scratch and set IsPersonAccount on create. There’s more information on Person Account record types on developer.salesforce.com here.

Testing and Modifying Existing Setup

The guide gives you a starting point for testing your setup with the newly enabled Person Account feature, and I want to expand on that. It’s possible that you’re going to need to undertake some configuration and development effort to ensure your existing setup is realigned to include the Person Account data model.

Given you have existing users currently active in your Production Salesforce org, it’s pretty safe to assume you’re already using the Account object in some way. This means you’re going to need to thoroughly test your existing use cases.

At this point, I’m hoping for your sake that you’ve got a fairly comprehensive suite of automated regression tests already set up for your Salesforce org, and some documentation of the configuration and customisations that have been made to the org. However, I know that isn’t always the case, so here are a few tips on testing to ensure you catch any issues before setting up Person Account in production.

User guides: if you have any training documentation, step through this in your sandbox and see if anything behaves differently. This could be a result of outdated documentation, or it could be a Person Account compatibility issue that you need to resolve.

Business super users / UAT: Identify a few key super users who can perform UAT, following their normal business processes in the sandbox and provide feedback to you on any issues they encounter.

Debug Logs are your friend: set up debug logs to catch the automation that is firing when a user is stepping through their normal use of Salesforce. See Salesforce’s Monitor Debug Logs help article here.

Metadata search: You can identify your existing metadata that references Account and Contact using VSCode, and use this to flag any particular areas of your org to focus testing on. My colleague Dimos has kindly contributed a how-to for searching metadata in VSCode:

  1. Get the metadata locally

Once you have access to the repository that stores the code base for the org, clone that into your local machine. This can be done via the command line (‘git clone {repository URL}’), through a Git client or even through VSCode directly and is the foundation for viewing the full picture of all metadata in the production org.

  1. The fun stuff

Within VS Code, navigate to the File Explorer (top left icon on the sidebar) and find the folder of Apex Classes, Aura components, or anything else you want to do a search on.

Right click on that folder and click on ‘Copy Path’.

copy-path

Navigate to the Search section (the magnifying glass icon right under the File Explorer on the top left). From here, you need to enter some keywords of whatever you are searching (in our case Account and Contact references) in the first box and paste the path of the folder you copied earlier in the ‘files to include’ box. If you can’t see this box, click on the 3 dots to the right of these words to expand the section.

Pro Tip: If you have many different keywords and lots of results for each one, you can retrieve a unified view of multiple sets of results by using a regular expression. This is shown in the screenshot below. To use this, click on the ‘Use Regular Expression’ option to the right of the search box (a square with an asterisk logo). The search string I used was simply '(Account|Contact)’ which makes a search on both keywords and lists out all files that either have an Account or Contact reference.

copy-path

And now you have your list of metadata items! (Thanks, Dimos!)

Change Management

Introducing Person Accounts after a Salesforce org is already live is a substantial change to your org which will impact your existing users. Make sure you remember to undertake change management activities to communicate with your users about what is going to change, when, and most importantly - WHY.

Stage your Deployment

There are a few steps involved in deploying Person Accounts to production and they may take some time, so you need to have a practice run in a staging environment to establish how much time this will take you. Your staging environment should be as production-like as possible - a newly refreshed Full Copy Sandbox is perfect for this.

While we’re on the topic of deployments, I strongly recommend locking your users out of your org during the deployment. A simple way to do this is freezing your users in bulk via data loader - Salesforce has a how-to on doing that here.

Your deployment steps would look something like:

  1. Freeze user access
  2. Backup your data
  3. Prepare your org for data importing - for example, switch off automation / integrations so you don’t trigger unwanted processes, like accidentally emailing all of your customers
  4. Get Salesforce to switch on Person Account access (have a chat to your Salesforce Account Executive about the timing of this - perhaps you can log a case in advance, or ask them to escalate the case for you, to minimise any wait time)
  5. Deploy your updated metadata, if you’ve had to change anything as a result of your testing
  6. Convert/upload your data to Person Accounts
  7. Test your deployment & data migration
  8. Switch your org “back on” - reverse any of the steps you did to prepare your org for data importing
  9. Unfreeze users
  10. Communicate the successful deploy to your users
  11. Celebrate!

I have written these tips based on a real world experience overseeing the implementation of Person Accounts in a real life Salesforce org and struggling to find a single source of comprehensive information and tips - so I hope you’ve found it useful. If you have any questions please reach out to me on Twitter @heyemilyhay.