A few years into most Sales Cloud careers you collect a short list of settings you treat with real fear, the ones you cannot quietly walk back if you get them wrong. Person Accounts sits at the top of that list. You enable it by raising a case with Salesforce Support, you wait a day or two, and from that moment the org is changed forever. There is no toggle to turn it off, no clean uninstall, nothing. I have watched a client enable it on a whim "just to see how it works" on a sandbox they later wanted to promote, and then spend weeks figuring out how to get back to a state they could ship.
The reason this matters so much is that the choice between Person Accounts and the standard Account-plus-Contact model is not a cosmetic UI preference. It decides the shape of your core data, how every Opportunity links to a customer, how leads convert, how storage scales, and how your integrations map records. Get it right and your B2C reps see one clean "person" record and never think about it again. Get it wrong and you are looking at a multi-month migration that re-links millions of child records, or a hybrid workaround you will be explaining to new joiners for the life of the org.
So before anyone raises that support case, it is worth slowing down and walking the decision properly. The good news is that the decision tree is short, and most of the hard cases reduce to a handful of questions about who your customer actually is.
What Person Accounts actually are, and when they fit
A Person Account is Salesforce's way of modelling a customer who is a private individual rather than a company. In the UI your rep sees a single "person" record, but underneath Salesforce stores two linked records, one Account and one Contact, paired one-to-one. That hidden pairing is the source of both the convenience and most of the gotchas I will get to later.
The standard B2B model is the opposite assumption: an Account is a company, and Contacts are the people inside it. You sell software to a manufacturer, and the IT manager you deal with is a Contact under that company's Account. Nobody would model that IT manager as a Person Account, because the company is the thing you are really selling to.
The decision genuinely comes down to a few questions asked in order. Is your customer an individual or a company? If it is a company, you are done, use B2B. If it is an individual, are they buying for themselves or representing an employer? A director purchasing on behalf of their firm is still a B2B relationship. Next, do you need to track one person related to several different companies, the way an advisor sits across multiple clients? If so you want B2B plus Account-Contact Relationships, not Person Accounts. Only once you have an individual buying for themselves, related to you alone, do Person Accounts become the right default.
I worked with a residential real-estate developer who sat cleanly at the end of that tree. Their customers are private buyers purchasing apartments for themselves. A spouse might co-sign, but it is a joint decision, not a buying committee that needs separate roles. Person Accounts were obviously correct. Each buyer became one record carrying birthdate, income range, and preferred-project fields, and a single buyer could carry several Opportunities over time as they bought additional units. The model disappeared into the background, which is exactly what you want.
The volume and storage reality nobody costs upfront
The convenience of Person Accounts has a price that only shows up at scale, and it is a price you should put in front of the client during discovery rather than discovering it yourself after go-live.
Because every Person Account is two records underneath, your storage is effectively doubled against a Contact-only footprint. For a real-estate developer with tens of thousands of buyers this is noise. For a consumer-finance client I advised, with around eight million customers, it is not. Eight million Person Accounts is sixteen million records before you count Opportunities and activity history, and that pushes data storage into territory you have to plan and budget for from day one. They accepted the trade because a simple B2C model was worth more to them than the storage line item, but they made that call with the number in front of them, which is the point.
Sharing is the other thing that gets subtle at volume. A Person Account shares through the Account owner, but the underlying Contact has its own sharing behaviour, and if those do not agree you get inconsistency. My standing recommendation is to leave the Contact org-wide default as Controlled by Parent and never get clever with it. The moment you customise Person Account sharing you are signing up to debug edge cases that are very hard to reason about.
The field, layout, and lead-conversion traps in daily use
Most of the operational pain with Person Accounts is not architectural, it is the day-to-day confusion of a record that carries fields from both an Account and a Contact. You will have a Phone field from the Account side and a Phone field from the Contact side, both visible, and reps cannot tell which one to fill. Email behaves the same way, where the Account email is usually empty and the real address lives on the Contact. The fix is unglamorous but essential: design the page layout deliberately, hide the duplicate Account-side fields, or rename them to something unambiguous like "Office Phone" versus "Mobile Phone." Skip this and your data quality erodes one confused rep at a time.
Lead conversion is the other place careful setup pays off. By default, a Lead with an empty Company converts into a Person Account, and a Lead with Company filled converts into an Account plus Contact. That works beautifully when your lead capture is consistent, and it breaks the moment it is not. If a rep types "Individual" into the Company field to be helpful, you either lose that note on conversion or you misroute the record entirely. In a mixed B2B and B2C org you handle this with separate Lead record types and conversion logic that respects them, and then you train reps on which record type to pick, because a wrong record type means a wrongly converted record and dirty data downstream.
A couple of integrations deserve a specific warning. Marketing Cloud syncs Accounts and Contacts separately, and a Person Account is a special case that does not follow the default rules. I have seen the same person receive every email twice, once via the Account sync and once via the Contact sync, because nobody set up a Person-Account-aware sync rule. If Marketing Cloud is in scope, design that sync rule before the first send, not after the first complaint.
When you got it wrong: hybrid beats migration
Sooner or later you will inherit, or create, an org where the original call was wrong, and what you do next depends heavily on which direction you are going.
The genuinely painful direction is moving an existing Contact-only model into Person Accounts. I took a retail-banking client through this, and there is no native "convert this Contact into a Person Account" operation. You back up everything, enable Person Accounts, then for every existing Contact you create a fresh Account-Contact pair, re-link every Opportunity, Activity, and Case to the new record, and finally retire the old records and the meaningless placeholder Account they all used to hang under. You test the script on ten thousand records in a sandbox before you go anywhere near production, you update every integration whose record IDs just changed, and you retrain the reps on an entirely new UI. That project ran about three months with a weekend of downtime, and my honest advice to anyone considering it is to avoid it unless the pain of the current model is truly unbearable.
The other direction, discovering you now need something Person Accounts cannot do, such as account hierarchy for a corporate buyer, is far more forgiving precisely because you do not try to migrate. You keep Person Accounts for the B2C segment and introduce a separate Business Account record type for the new corporate relationships. The two segments live side by side, each with its own page layouts, validation, and lead-conversion path. You pay for it in slightly more training complexity, but you avoid the migration entirely, and in practice this hybrid is the normal end state for banks and developers who serve both individuals and companies. If discovery shows any real chance of needing both, I now build the hybrid from the start rather than betting the org on a single model.
The principle underneath all of this is simple. Person Accounts is a one-way door, so treat the decision with the seriousness a one-way door deserves: validate the B2C scope twice, get the business owner's sign-off in writing, cost the storage at year five, and only then raise the case. Everything you do before that case is cheap, and almost everything you do after it is expensive.
Implementing or optimizing Sales Cloud? Our Salesforce team runs discovery, designs the sales process, and configures Sales Cloud on production engagements. Get in touch ->
See our full platform services for the stack we cover.
