Salesforce Person Accounts masking fails more often than architects expect, because Person Accounts are not a separate object with a tidy label. They are Account records wearing a Contact's clothes, and most masking rule libraries are built around object names rather than field prefixes. If your masking tool maps rules to "Account" and "Contact" as two clean buckets, it will miss the PII sitting inside the hybrid fields that make Person Accounts work in the first place.
That gap matters more than it sounds. Industries that lean on Person Accounts, like insurance, healthcare, and B2C retail, often store the bulk of their regulated PII on exactly those hybrid fields. A sandbox refresh that skips them isn't a minor oversight. It's an unmasked customer database sitting behind a login screen that every contractor, offshore QA tester, and new hire can reach.
What Makes a Person Account Different
A standard Salesforce org separates companies from people: Accounts represent organizations, Contacts represent the humans tied to them. Person Accounts collapse that structure for orgs that sell to individuals rather than businesses. Enable Person Accounts and Salesforce creates a single record that behaves like an Account for reporting but stores individual-level data through a shadow Contact that most admins never interact with directly.
Under the hood, Salesforce handles this by prefixing a set of Contact fields with the word "Person" and exposing them on the Account object. PersonEmail, PersonMobilePhone, PersonBirthdate, PersonMailingStreet, and PersonTitle all live on the Account record, even though they describe an individual, not a company. Every Person Account also carries a PersonContactId, a system-generated link to an invisible Contact record that Salesforce maintains behind the scenes.
This design makes Person Accounts convenient for B2C data models. It also makes them a structural trap for masking tools that were written with a B2B mental model in mind, where Accounts hold company names and Contacts hold people's details, cleanly separated by object.
Where Standard Masking Rules Break
Most masking configurations start from object-level field discovery. An admin or a masking tool scans the Account object, flags fields like Name, BillingStreet, and Phone, and builds masking rules around them. It does the same for Contact: Email, MobilePhone, MailingAddress, Birthdate. Two objects, two rule sets, done.
Person Account fields do not show up cleanly in that pass. Depending on how the discovery tool queries the schema, PersonEmail and PersonMobilePhone can get filtered out entirely, treated as system fields, or left unmapped because they only appear on Accounts where IsPersonAccount equals true. A masking rule written for the generic Account object will run, report success, and leave every PersonEmail value untouched, because from the rule's point of view, it never saw that field as a target.
There's a second failure mode worth flagging: referential integrity around the shadow Contact. Because PersonContactId points to a system-managed Contact record, masking tools that key off ContactId relationships for consistency, say, making sure the same person's email is masked identically across Account, Contact, and related Opportunities, can lose that linkage entirely for Person Accounts. The result is a sandbox where a customer's real email survives on the Person Account record while a fake one shows up on a related Case, with no obvious reason why they don't match.
Industries Where This Gap Is Not an Edge Case
Person Accounts are not a niche configuration. They are the default data model for a wide range of regulated industries, which is exactly where unmasked PII does the most damage.
- Insurance: individual policyholders, beneficiaries, and claimants are typically modeled as Person Accounts, carrying health details, payout history, and national ID numbers.
- Healthcare and life sciences: patient and provider orgs built on Health Cloud use Person Accounts extensively, often alongside Shield encryption, which can mask the fact that underlying field values are still real in lower environments.
- Financial services: wealth management and retail banking orgs on Financial Services Cloud use Person Accounts for individual clients, with sensitive fields covering net worth, account numbers, and tax identifiers.
- B2C retail and membership orgs: loyalty programs and direct-to-consumer brands use Person Accounts as the core customer record, often the single largest table of real names, emails, and addresses in the org.
I'd argue this is the single most under-discussed gap in Salesforce sandbox masking today. Vendors talk about Shield encryption and Named Credentials because they sound sophisticated. Meanwhile, a straightforward field-naming convention quietly lets real patient and policyholder data ride along into every sandbox refresh.
The Fields Most Often Left Unmasked
The table below lists the Person Account fields that show up most often in audit findings, along with why each one tends to slip past standard masking configurations.
| Field | Why It Gets Missed |
|---|---|
| PersonEmail | Not recognized by Account-only field discovery; often absent from Contact rule sets since it is not a Contact API name |
| PersonMobilePhone / PersonHomePhone | Filtered out by rules that match on "Phone" patterns tied to standard Contact field names |
| PersonMailingStreet/City/PostalCode | Confused with BillingAddress fields already covered by Account rules, assumed redundant |
| PersonBirthdate | Treated as a custom or system field rather than sensitive PII requiring date-shifting |
| PersonTitle | Low priority in most rule libraries despite revealing professional or personal status |
| Custom Person* fields | Org-specific fields like PersonNationalID__c rarely get flagged unless someone manually audits the schema |
Notice the pattern: almost none of these are obscure or exotic field types. They are ordinary PII categories, just living under an unfamiliar naming convention that a generic masking rule set was never written to match.
Building a Masking Rule That Actually Covers Person Accounts
Fixing this starts before any masking rule gets written. Field discovery has to query the schema with IsPersonAccount in mind, not just object API names. That means explicitly pulling the full list of Person-prefixed fields exposed on the Account object in your org, since the exact set varies depending on which Contact fields your org has enabled for Person Account sync.
From there, rules need to treat PersonEmail, PersonMobilePhone, and PersonBirthdate with the same masking logic you already apply to standard Contact Email, MobilePhone, and Birthdate. Reuse your existing fake-data generators rather than inventing new ones. There's no reason a Person Account's email should follow different realism rules than a Contact's.
Referential consistency needs separate attention. If your masking approach relies on deterministic hashing so the same source value always maps to the same fake value across objects, apply that same hashing key to PersonEmail and PersonMobilePhone as you do to the equivalent Contact fields. This keeps a masked customer's identity consistent across their Person Account record, related Cases, and any Opportunities tied to them, which matters if your QA team relies on cross-object lookups during testing.
One more practical step: check whether Person Accounts are even enabled in your sandbox before assuming rules will apply. Person Accounts require a specific Account record type and a feature flag that Salesforce Support has to turn on. Full sandboxes typically inherit this setting from production, but partial copy sandboxes built from a custom template can sometimes exclude the record type, which silently breaks any masking rule scoped to it.
Validating the Masking Actually Worked
After any refresh, run a direct query against PersonEmail and PersonMobilePhone on a sample of records rather than trusting the masking job's success log. Logs report that a rule executed, not that every targeted field actually changed value.
Spot-check a Person Account that you know existed in production, ideally one tied to a real customer whose email you recognize. If that email or phone number shows up unchanged in the sandbox, the masking rule didn't reach it, regardless of what the job summary claims.
Finally, check downstream exposure: reports, dashboards, and list views built on Person Account fields. A masking job can succeed at the data layer while a cached report snapshot, an Einstein-generated insight, or a Chatter post referencing a customer's name still surfaces the real value. Masking Person Accounts correctly means checking the field, not just the rule, and checking where that field shows up next.
Frequently Asked Questions
Why do Person Accounts need separate masking rules from regular Accounts and Contacts?
Person Accounts store individual PII, like email and mobile phone, on fields with a Person prefix that live directly on the Account object. Masking rules built around standard Account or Contact field names typically do not match these Person-prefixed fields, so they get skipped entirely during a mask run. Without a rule written specifically for PersonEmail, PersonMobilePhone, and similar fields, that data passes into the sandbox unmasked.
Which Salesforce fields are most commonly missed when masking Person Accounts?
PersonEmail, PersonMobilePhone, PersonHomePhone, PersonMailingStreet, PersonBirthdate, and PersonTitle are the fields most often left unmasked. Custom fields that follow the same Person naming pattern, such as an org-specific PersonNationalID field, are frequently missed too since they rarely appear in a default field discovery scan.
Which Salesforce industries are most exposed to this Person Account masking gap?
Insurance, healthcare, financial services, and B2C retail orgs rely on Person Accounts as their core customer data model, not as an occasional configuration. These industries also tend to handle the most heavily regulated PII categories, including health details, financial account numbers, and national identifiers, making an unmasked Person Account field a significant compliance exposure.
Does Salesforce Shield encryption protect Person Account PII in sandboxes instead of masking?
No. Shield encryption protects data at rest in the database but decrypts automatically for authorized users with field-level access, which includes most sandbox users. It does not replace real values with fake ones, so a Person Account's real email or birthdate remains fully visible to anyone with normal field permissions even when Shield is active.
How do you confirm Person Account masking actually worked after a sandbox refresh?
Run a direct query against PersonEmail and PersonMobilePhone on a sample of records rather than relying on the masking job's completion log. Pick a Person Account tied to a real customer you recognize and check whether the field value has actually changed. Also review reports and dashboards built on those fields, since cached report data can still display real values even after the underlying record is masked.