Person Accounts

Why Person Accounts Matter
Salesforce was originally designed around a business-to-business (B2B) model: an Account represents a company, and Contacts represent the people who work there. However, many organizations sell directly to individuals (B2C) — think financial advisors, real estate agents, healthcare providers, retailers, or non-profits dealing with individual donors. For these businesses, forcing a human being into a 'company' record with a separate contact underneath it is awkward and creates data clutter. Person Accounts solve this problem by allowing an individual consumer to be stored as a single record that behaves like both an Account and a Contact. Understanding Person Accounts is important for the Advanced Administrator exam because they intersect with data modeling, sharing and security, record types, page layouts, and reporting — and because enabling them is an irreversible decision with significant consequences for the org.

What Is a Person Account?
A Person Account is a special kind of Account record that represents an individual rather than a business. Behind the scenes, Salesforce creates both an Account record and a Contact record and links them together, but presents them to the user as one unified record. The user sees a single page with fields such as First Name, Last Name, Email, Phone, Birthdate, and Mailing Address, all appearing to live on the Account.

Key characteristics:
• Person Accounts use Account record types of a special type. When Person Accounts are enabled, Salesforce creates a default 'Person Account' record type. You can create additional Person Account record types, and each one is flagged internally as a person account record type.
• The Name field on a Person Account is actually composed of First Name and Last Name (plus Salutation, Middle Name, and Suffix if enabled), which are Contact fields surfaced on the Account.
• Person Accounts have an IsPersonAccount field (checkbox) that is true for person accounts and false for business accounts. This is useful in reports, list views, validation rules, and formulas.
• Contact fields appear on the Person Account with a __pc suffix for custom fields (e.g., Loyalty_Tier__pc) instead of the standard __c suffix used for custom Account fields. Standard contact fields appear with a 'Person' prefix in the API (e.g., PersonEmail, PersonMobilePhone, PersonBirthdate).
• A Person Account cannot have Contacts under it in the traditional sense, because the record itself is the contact. The Contacts related list does not appear on Person Account layouts.
• Person Accounts can have Opportunities, Cases, Activities, Campaign Membership, Community/Experience Cloud users, and most other standard related objects.

How Person Accounts Work

1. Enabling Person Accounts
Person Accounts are not turned on by default. Historically you had to contact Salesforce Support; in current orgs an administrator can enable them from Setup > Account Settings once the prerequisites are met. The prerequisites are strictly enforced:
• The Account object must have at least one record type created.
• User profiles that have Read permission on Accounts must also have Read permission on Contacts (because a person account is also a contact).
• The organization-wide default (OWD) sharing setting for Contacts must be set to Controlled by Parent, OR the Account and Contact OWDs must be set to the same level (e.g., both Private or both Public Read/Write). The exam frequently tests this point.
• It is strongly recommended to enable Person Accounts in a sandbox first, because once enabled in production, Person Accounts cannot be disabled. This irreversibility is one of the most commonly tested facts.

2. Record Types and Page Layouts
Once enabled, Salesforce creates a Person Account record type and a Person Account page layout. Business accounts continue to use business account record types. You can create multiple Person Account record types (for example, 'Individual Customer' and 'Individual Prospect') and assign them to profiles. Person Account page layouts are managed separately from business account layouts and can include Contact fields. If a profile is not assigned any Person Account record type, users with that profile cannot create person accounts.

3. Sharing and Security
Because a Person Account is simultaneously an Account and a Contact, sharing is driven by the Account. Contact sharing is effectively controlled by the parent account for person accounts, which is why the Contact OWD must be Controlled by Parent (or match the Account OWD). Account sharing rules, manual sharing, the role hierarchy, and account teams all apply to Person Accounts. Field-level security for Contact fields applies to the corresponding person-account fields.

4. Converting Leads
When Person Accounts are enabled, lead conversion gains an extra option. If a lead has no Company value (the Company field is blank), the converted lead becomes a Person Account. If the Company field is populated, it converts into a business Account plus a Contact. You can also choose to convert into an existing person account. Some orgs make the Company field optional on leads specifically to support this flow.

5. Reporting and List Views
Person Accounts appear in both Account and Contact reports. Standard reports include 'Accounts and Contacts' report types, and you can filter by the Is Person Account field to isolate individuals from businesses. Many standard list views and reports include a Person Account icon to differentiate them from business accounts.

6. Limitations and Considerations
• Person Accounts consume two records of storage (one Account plus one Contact) and count against data storage accordingly.
• Person Accounts cannot be merged with business accounts; you can only merge person accounts with other person accounts, and business accounts with business accounts.
• You cannot convert a business account to a person account directly through the UI, or vice versa; a data migration (export, delete, re-import) is required.
• Account Hierarchy: a Person Account cannot be a parent account, and the Parent Account field is not available on person account layouts.
• Some features such as Account Contact Relationships (contacts to multiple accounts) and certain partner portal features have specific behaviors or limitations with Person Accounts.
• Person Accounts in the Data Loader require careful handling: you insert them into the Account object with the person account RecordTypeId and use First Name / Last Name rather than Name.
• Duplicate rules and matching rules can be created specifically for Person Accounts, and Salesforce provides standard matching rules for them.
• Picklist fields on Contact that are also on the Account must be kept in sync in some cases; and Contact-based automation such as Contact triggers can fire when person accounts are created.

Exam Tips: Answering Questions on Person Accounts

Tip 1 — Recognize the B2C scenario. When a question describes a company that sells to individuals, consumers, patients, students, or individual donors, and mentions difficulty storing people without a company, the answer is almost always Person Accounts rather than a custom object or 'bucket' accounts like 'Individual'.

Tip 2 — Memorize the prerequisites. Expect questions like 'What must be true before Person Accounts can be enabled?' The correct answers involve: at least one Account record type exists; profiles with Read on Accounts also have Read on Contacts; and the Contact OWD is Controlled by Parent (or matches the Account OWD). If an answer option mentions Contact OWD set to Private while Account is Public Read/Write, that is a distractor.

Tip 3 — Irreversibility. Any option suggesting you can 'turn off' or 'disable' Person Accounts later is wrong. The exam loves to test that enabling Person Accounts is permanent and should be tested in a sandbox first.

Tip 4 — Lead conversion rule. Remember: blank Company field = Person Account on conversion; populated Company field = Business Account + Contact. If a question asks how to let sales reps convert consumer leads into person accounts, the answer involves leaving Company blank and having Person Accounts enabled.

Tip 5 — Know the API naming. Custom contact fields appear on Person Accounts with __pc, standard ones with a Person prefix (PersonEmail, PersonMobilePhone). The IsPersonAccount checkbox is used to filter reports, list views, and build validation rules or formulas that behave differently for individuals versus businesses.

Tip 6 — Sharing flows from the Account. If a question asks how to control visibility of person accounts, think in terms of Account sharing (OWD, role hierarchy, sharing rules, account teams), not Contact sharing. Contact sharing for person accounts is always controlled by the parent.

Tip 7 — Watch for merge and hierarchy traps. You cannot merge a person account with a business account, a person account cannot be a parent in the account hierarchy, and a person account cannot have child contacts. These frequently appear as 'which of the following is NOT possible' questions.

Tip 8 — Storage and data loading. If a question discusses storage planning, remember each person account counts as two records. For Data Loader questions, remember you load person accounts into the Account object with a person account record type and use First Name and Last Name fields.

Tip 9 — Eliminate the 'custom object' distractor. Questions sometimes offer creating a custom 'Individual' object as an alternative. This is usually wrong because it loses native functionality (Opportunities, Cases, Campaigns, Activities, Experience Cloud users) that Person Accounts retain.

Tip 10 — Read carefully for 'record type' clues. If users cannot create person accounts, the most likely cause is that their profile has not been assigned a Person Account record type, or the Person Account page layout has not been assigned. Check record type and layout assignments before suspecting permissions.

Summary
Person Accounts let Salesforce model individual consumers as a single record that merges Account and Contact behavior. They require specific prerequisites (Account record type, matching profile permissions, Contact OWD Controlled by Parent), are permanent once enabled, convert from leads with a blank Company field, share based on the Account, consume two records of storage, and carry a handful of limitations around merging, hierarchy, and conversion. Master these facts and the scenario-recognition skills above, and you will handle any Person Account question on the Advanced Administrator exam with confidence.