Salesforce PII field discovery is the process of identifying every field, standard or custom, that stores personal data before you write a single masking rule. Skip it and you get a masking policy that scrubs the obvious fields (Email, Phone, MailingStreet) while leaving PII sitting untouched in a custom field nobody remembers building three years ago. A masking tool only protects what it's told to protect. Nobody tells it about the field it doesn't know exists.
This is the step most Salesforce teams rush through, and it's the step that causes the most GDPR exposure. Not because the masking engine failed, but because the inventory feeding it was incomplete.
Masking Rules Are Only as Good as Your Field Inventory
Every masking tool, ours included, works from a list. You tell it which fields hold PII, and it replaces the values in those fields with realistic fakes before a sandbox refresh completes. The tool doesn't scan your org and guess. It executes the rules you gave it.
That means the entire compliance outcome depends on how thorough the discovery phase was. A team that spends two days mapping fields and two hours configuring rules will end up more compliant than a team that spends two hours mapping fields and two days tuning rules. Discovery is the unglamorous work that determines whether the rest of the project actually works.
I've seen orgs treat this as a one-time exercise done during initial setup, then never revisit it. That's backwards. Salesforce schemas change constantly, and every new custom field is a candidate for exposure until someone classifies it.
Where Salesforce Hides PII You Won't Think to Mask
The fields everyone masks are the easy ones. Email, Phone, MailingAddress, Fax, SSN__c if someone was honest enough to name it that. The fields that get missed are the ones that don't announce themselves.
| Field type | Example | Why it's missed |
|---|---|---|
| Formula fields | Full_Name__c concatenating First + Last | Looks derived, not stored, but it renders PII in reports and exports |
| Long text areas | Description, Notes, Case Comments | Free text where reps paste emails, addresses, and ID numbers manually |
| Rich text and HTML fields | Custom email body fields | Often excluded from masking scope because they're treated as content, not data |
| Geolocation fields | Home_Location__c | Latitude and longitude can pinpoint a person's residence |
| Encrypted fields (Shield) | National_ID__c | Teams assume encryption equals compliance and skip masking entirely |
| Lookup and junction fields | Related contact on a custom object | The PII lives one hop away, not in the object you're scanning |
Long text areas deserve special attention. Support reps and account managers paste customer emails, home addresses, and sometimes payment references directly into Case Comments or Description fields because it's faster than the proper field. No masking rule targets free text by default, which means this is often the single largest source of leaked PII in a sandbox that otherwise looks clean.
Standard Objects Aren't the Whole Story
Most PII discovery starts and ends with Contact, Lead, and Account. That's necessary but nowhere near sufficient. Salesforce orgs accumulate custom objects for years, and a good number of them store personal data under names that give no hint of it.
A custom object called Site_Visit__c might have a Visitor_Email__c field. An object called Warranty_Claim__c might store a customer's home address for shipping purposes. An object called Survey_Response__c might carry free-text answers where respondents typed their own contact details unprompted. None of these show up if you're only auditing the objects with obvious names.
Person Accounts complicate this further, since PII fields live on both the Account and the underlying Contact record, and a discovery process that only checks one layer will miss the other. Chatter posts, files, and attachments carry the same risk in a different format, but that's a large enough problem to warrant its own inventory pass rather than a footnote here.
A Practical Process for Building a PII Inventory
Discovery doesn't need to be exotic. It needs to be systematic and repeated. Here's the sequence that produces a usable inventory rather than a guess dressed up as one.
- Export the full field list for every object using Setup or the Metadata API, not just the objects you assume matter.
- Flag fields by name pattern first (email, phone, ssn, dob, address, name) to catch the obvious layer quickly.
- Sample actual record data for each remaining field, because field labels lie and free text fields hide anything.
- Interview business users in support, sales ops, and finance, since they know which fields get used as a dumping ground for PII the schema was never designed to hold.
- Trace lookup relationships outward from every object that touched PII, because a related record one hop away is still exposure.
- Document the classification decision for every field, including the fields you decide are safe, so the next person doesn't have to redo the analysis.
That last point matters more than it sounds. A field marked safe today with no documented reasoning gets re-flagged as risky by the next admin, who then wastes a day re-verifying something already settled. Write down why, not just what.
Automating Discovery With Metadata and SOQL
Manual review works for a first pass but doesn't scale to orgs with thousands of fields across hundreds of objects. Two approaches make this faster without making it sloppier.
The first is metadata-driven pattern matching: pull every field's API name, label, and description via the Tooling API or Metadata API, then run it against a library of PII keyword patterns (email, phone, address, dob, ssn, passport, national, iban, tax). This catches maybe 70% of true positives on the first pass, and it's fast enough to rerun after every release.
The second is data sampling: query a small batch of records per object and run the actual field values through pattern detection, looking for email formats, phone number formats, and address-like strings in fields the name-based scan didn't flag. This is what catches the free-text problem, since a field called Additional_Notes__c will never match a name pattern but will absolutely match a regex looking for something that resembles an email address. Neither method alone is sufficient. Together they get you close enough that manual review becomes a verification step instead of the whole job.
Keeping the Inventory Alive After Every Release
A PII inventory built once and never updated has a shelf life of about one release cycle. Someone adds a custom field for a new integration, a consultant builds an object for a six-month project, a flow starts writing customer emails into a field never meant to hold them. Six months later that field is in production, feeding every sandbox refresh, and nobody classified it.
The fix is to treat field classification as part of the change process, not a separate audit. Any deployment that adds a custom field should require a one-line classification: PII or not, and if PII, which category. This takes less effort at the point of creation than it does to retrofit six months later across every sandbox that inherited the gap.
MaskEzee reads field metadata on every scheduled refresh and flags new fields that match PII patterns, so an unclassified field surfaces before the next sandbox copy runs rather than after. That doesn't replace human judgment on the ambiguous cases, but it closes the gap between when a field is created and when someone actually looks at it, which in most orgs is the real source of exposure.
Frequently Asked Questions
What is Salesforce PII field discovery?
It's the process of identifying every field across all Salesforce objects, standard and custom, that stores personal data such as names, emails, addresses, or ID numbers. This inventory is built before configuring masking rules, since a masking tool can only protect fields it's explicitly told about. Without discovery, masking rules typically cover obvious fields like Email and Phone while missing custom fields, free text areas, and related objects that also carry PII.
Why do free text fields cause the most missed PII?
Fields like Case Comments or Description were designed for general notes, not personal data, so they're rarely included in a masking scope by default. In practice, support reps and sales users paste customer emails, home addresses, and other identifiers into these fields because it's faster than using the correct field. Standard name-based scans won't catch this, since the field label gives no indication that PII lives inside the actual record values.
Does Shield Platform Encryption remove the need for masking?
No. Encryption protects data at rest and in transit within production, but sandbox environments used for development and testing still expose decrypted values to anyone with access. Teams that assume encrypted fields are automatically safe often skip masking those fields entirely, which leaves real personal data readable in every sandbox copy.
How often should a PII field inventory be updated?
It should be reviewed every time a schema change is deployed, not on a fixed calendar schedule. New custom fields, objects, and integrations are added continuously in most orgs, and any of them can introduce personal data that existing masking rules don't cover. Tying classification to the deployment process, rather than a periodic audit, closes the gap between when a field is created and when it gets masked.
Can automated tools fully replace manual PII field review?
Automated pattern matching against field names and sampled data values catches a large majority of PII fields quickly, but it isn't complete on its own. Ambiguous cases, like a custom field with a generic name that occasionally holds a customer's ID number, still need a human to confirm the classification. The practical approach uses automation to narrow the list and manual review to verify the edge cases.