--- title: "Person accounts: the switch you cannot undo" url: "https://trailassembly.com/person-accounts-the-one-way-door/" topic: "Architecture" published: "2026-09-13T09:23:12+00:00" updated: "2026-10-06T13:54:22+00:00" --- # Person accounts: the switch you cannot undo **Straight answer:** enabling person accounts cannot be undone. Not by you, not by Salesforce support, not by a data fix. It permanently changes the Account object, makes [record types](https://trailassembly.com/record-types/) mandatory on Account, doubles your page layout matrix and changes how every integration has to create an Account. Enable it if you genuinely sell to individuals who have no employer in your data model. If you are not certain, you are not ready. ## What actually happens when you turn it on A person account is one Account record backed by a hidden Contact record. Both exist, both consume storage, and `PersonContactId` on the Account points at the Contact. Every person account therefore costs two rows of your data storage allocation rather than one. The Account object grows person fields. Standard contact fields appear as `PersonEmail`, `PersonMobilePhone`, `PersonBirthdate`, `PersonTitle` and so on. Custom contact fields appear on Account with a `__pc` suffix. They exist on business accounts too, blank and meaningless, which is its own reporting annoyance. Account Name changes behaviour. On a person account it is a read-only compound of First Name and Last Name, and you populate `FirstName` and `LastName` instead. Code doing `new Account(Name = 'something')` against a person account record type fails. ## Record types stop being optional You need at least one business account record type and one person account record type, and Contact’s [org-wide default](https://trailassembly.com/org-wide-defaults/) has to be Controlled by Parent before Salesforce will enable the feature at all. From then on, every layout decision is made twice. Every profile needs assignments for both record types. Every [list view](https://trailassembly.com/salesforce-list-views-and-filters/), Lightning page assignment and [validation rule](https://trailassembly.com/validation-rule-vs-flow/) that assumed one shape of Account now needs an `IsPersonAccount` check or a record type filter. The permanent doubling of Account configuration work is the real cost, not the enablement. ## What it does to integrations This is where the real bill arrives. - Inserting a person account requires a person account RecordTypeId and `LastName`, not `Name`. Any integration that creates Accounts needs a branch. - The backing Contact cannot be created or deleted independently. Deleting the Account deletes the Contact. - Integrations that create Contacts under Accounts will happily create a business-style Contact attached to a person account, producing a record that looks like a duplicate and reports like one. - Merging is constrained: a person account merges with a person account, a business account with a business account. - Managed packages vary in their support. Check the AppExchange listing for every package you depend on before enabling, because “supports person accounts” is not universal. [Lead conversion](https://trailassembly.com/lead-conversion-field-mapping/) also changes. With person accounts enabled, a lead with a blank Company field converts into a person account rather than failing. That is convenient and it is also a new way for bad data to create records you did not plan for. ## Reporting gets harder, not easier Person accounts appear in Account reports and, through the backing Contact, in Contact reports. A report joining Accounts and Contacts counts a person account on both sides. Standard report types built for a business model need reviewing one by one, and any report filtered on the existence of a Contact will behave differently. Build the `IsPersonAccount` filter into your report types early. Retrofitting it across a mature reporting library is tedious and easy to get half right. ## Who should enable it Enable it if your customers are individuals and the account-contact pair adds nothing: retail banking, consumer insurance, healthcare patients, education applicants, membership organisations. The model fits and the alternative (a fake Account per person) is worse. Do not enable it because ten per cent of your customers are individuals and you want tidy data. The mixed model is the expensive one. For a small individual segment inside a business-to-business org, a household or bucket Account with real Contacts under it costs a naming convention and no permanent object change. Contacts to Multiple Accounts covers a surprising number of the remaining cases. ## Frequently asked **Can I test it in a sandbox first?** Enable it in a developer sandbox and run your integrations against it. That sandbox is then permanently a person account org, so use one you are willing to refresh from a pre-enablement production copy. **Can I convert existing business accounts into person accounts?** Not as a supported UI operation, and any API route is a migration project with its own data risks. Plan as though the answer is no. **Does it cost extra?** The feature itself is included in the relevant editions. The storage does cost you, since each person account occupies two records. **How do I undo it?** You do not. You can stop creating person accounts and hide the record type, but the object changes and the enabled flag stay. A new org is the only clean exit. --- Source: https://trailassembly.com/person-accounts-the-one-way-door/ Trail Assembly — independent Salesforce write-ups.