What is Person Accounts in Salesforce
What a Person Account actually is, the B2C use cases that justify it, how to enable and create one, and the do's and don'ts nobody tells you until after you've clicked Enable in production.
Swarnil Singhai
4 min read
Salesforce's standard data model assumes your customer is a company, with people attached to it. That works beautifully for B2B and falls apart the second you sell to individuals: patients, students, retail buyers, policyholders. Person Accounts are the fix. A single record that is technically an Account and a Contact at the same time.
Genuinely useful. Also completely irreversible once you turn it on. Which is exactly why we're doing the don'ts before the dos.
The problem nobody warns freshers about
Open a fresh org and the model is clean. Account is a company. Contact is a human who works at that company. Opportunity hangs off the Account. Every Salesforce demo you've ever sat through runs on this.
Now sell insurance to Rahul.
Rahul does not have an org chart. He has a phone number and strong opinions about your claims process. So teams improvise, usually one of two ways. Either they create a fake Account for every single customer named "Rahul Verma" with exactly one Contact inside it, or they create one giant bucket Account called "Retail Customers" and dump 400,000 Contacts under it. The first bloats your data. The second breaks sharing, reporting and every sales rep's will to live.
Person Accounts exist because Salesforce got tired of watching both.
So what is a Person Account, exactly
It's one record the platform treats as an Account and a Contact simultaneously.
Save a Person Account and Salesforce quietly writes two rows: an Account row and a Contact row, stitched together by a PersonContactId field on the account. Person-flavoured fields like PersonEmail, PersonMobilePhone and PersonBirthdate sit on the Account object. A boolean called IsPersonAccount flags it. The list view icon even changes to a little person, which is the closest Salesforce gets to a wink.
The practical payoff is this: anywhere the platform expects a Contact (Cases, Campaign Members, email, Experience Cloud users) the Person Account can play Contact. Anywhere it expects an Account (Opportunities, Contracts, Assets, Orders) it plays Account. That's the whole trick. Two objects wearing one trenchcoat.
Where you'd actually use one
Person Accounts earn their keep whenever the customer is the human:
- Healthcare and life sciences. The patient is the customer. Health Cloud is built assuming Person Accounts.
- Banking, wealth and insurance. Account holders and policyholders. Financial Services Cloud ships with them enabled.
- Retail and e-commerce. Shoppers, loyalty members, order history against a single individual.
- Telecom, utilities and subscriptions. A subscriber with contracts, assets and a billing relationship, who is not a business.
- Travel and hospitality. Guests, frequent flyers, booking history per person.
- Public sector. Constituents and case management. Public Sector Solutions supports them natively.
- Education. Students, applicants and alumni, although note that EDA has its own household-based model, so check which pattern your implementation follows before assuming.
One thing worth saying out loud: this is not either/or. Business accounts and person accounts happily coexist in the same org. If you sell software to companies and courses to individuals, running both is the normal setup, not a workaround.
How to enable and create one
Three prerequisites. The Account object needs at least one record type. Profiles with Read on Accounts need Read on Contacts. And your org-wide defaults must have Contact set to Controlled by Parent, or both Account and Contact set to Private.
Enabling it. Since Summer '22 you no longer file a support case. Go to Setup, type Person Accounts in Quick Find, select it, hit Check Readiness, then Enable Person Accounts, then confirm the warning. Read that warning. It's not decoration.
After enabling. Salesforce generates a Person Account record type and a default page layout for you. Then you assign the record type to profiles or permission sets, set the default business and person record types, and build a proper page layout, because the auto-generated one is a junk drawer.
Creating a record. App Launcher, Accounts, New. Pick the Person Account record type. Notice the form now asks for First Name and Last Name instead of Account Name. That's it. You've made a human.
Do all of the above in a Developer Edition org or a scratch org. Not the sandbox that refreshes from production next Thursday. Not production. Especially not production.
The don'ts
Don't enable it in production "just to have a look." It cannot be switched off. Not by you, not by an admin with more permissions, not by Salesforce Support. If you read one sentence in this post, make it that one.
Don't ignore storage. A Person Account consumes both account and contact storage. Roughly double the footprint per customer, which matters at B2C volume.
Don't assume your managed packages cope. Plenty of AppExchange apps, particularly older CPQ, billing and marketing tools, are written assuming Account and Contact are separate records. Check compatibility before you commit, not after go-live.
Don't forget lead conversion. A Lead with a blank Company field converts into a Person Account. If your web-to-lead form doesn't populate Company, you may start growing person accounts nobody planned for.
Don't reuse your B2B reports. Account reports now return people. Contact reports return person accounts. Filter on IsPersonAccount or your numbers will lie to you in a meeting.
Don't hardcode your integrations. Middleware that expects one Account ID and one Contact ID now meets a record holding both. Field mappings need revisiting.
Don't skip duplicate and matching rules. Consumer data is messy. Three Rahul Vermas with three phone numbers is a Tuesday.
The dos
One human, one record. No dummy accounts, no bucket account, no 400,000-contact monolith.
One page for your agents. Cases, orders, assets and activity history all sit on a single record. Handle time drops because nobody is hunting for the other half of the customer.
Native support where it counts. Health Cloud, Financial Services Cloud, Public Sector Solutions, Loyalty Management, B2C Commerce and Experience Cloud customer licenses all understand Person Accounts out of the box.
Reporting stops being a join exercise. Lifetime value per individual becomes a normal report instead of an archaeology project.
Sane B2C behaviour everywhere else. Campaign members, case contacts, community users, duplicate management, activities. All supported.
When to skip it
Low B2C volume and no industry cloud in your roadmap? The old pattern of a household account plus Contacts to Multiple Accounts still works, and crucially it's reversible. Also worth knowing: the Individual object is about consent and privacy preferences. It is not a lightweight Person Account, and swapping one for the other will not end well.
The short version
Person Accounts aren't a hack. They're Salesforce acknowledging that not every customer files a corporate tax return. The decision is architectural, permanent, and best made before your first data load rather than during your third.
Sleep on it. Then sandbox it. Then decide.
Building your Salesforce foundations? The Data Model Basics track covers Accounts, Contacts and relationships from scratch, in order, for free.
