Salesforce data masking fields fall into three groups most teams never separate: obvious PII on standard objects, custom fields nobody remembers adding, and relationship fields that leak sensitive data sideways through lookups. Get the list wrong in either direction and you end up with a sandbox that's either a compliance liability or so scrambled it's useless for testing. The fix isn't a better masking tool. It's a proper field audit before anyone clicks run.
The Standard Fields Everyone Masks (and Still Gets Wrong)
Every org masks Contact.Email and Contact.Phone. Most remember Lead.Email too. Fewer think about Contact.MailingStreet, MailingCity, and MailingPostalCode together, which combined with a name is enough to identify someone even without an email address.
Account records carry their own blind spots. BillingAddress and ShippingAddress fields get masked, but AccountNumber and Site fields often slip through because they don't read as personal. If AccountNumber maps to a government ID or a customer-facing account reference, it needs the same treatment as email.
Case and Opportunity records introduce a subtler problem: free-text fields. Description, Case Comments, and any long-text-area field can contain pasted email threads, phone numbers, or pasted support tickets with full customer identities inside them. Standard field-level masking tools that only target structured fields won't touch this text, which means the data walks straight into your sandbox untouched.
The Custom Fields Nobody Audits
This is where most masking projects actually fail. Every org we've worked with has at least a dozen custom fields holding sensitive data that was never flagged because nobody owns the field inventory. A custom field called National_ID__c added four years ago by a developer who's since left the company is a common find. So is Date_of_Birth__c sitting unmasked on a custom object nobody remembers building.
Integration-created fields are worse. Middleware and ETL tools frequently write customer data into staging fields with names like Temp_Customer_Data__c or Sync_Payload__c, sometimes storing an entire JSON blob of a customer record in one long-text field. These fields rarely show up in anyone's data dictionary because they were never meant to be permanent. They just never got cleaned up.
The honest fix is a scheduled audit, not a one-time project. Pull a full schema export twice a year and grep field labels and API names for patterns like ssn, dob, tax, passport, id_number, and salary. It's tedious. It's also the only way to catch fields added since the last masking run.
Related Object Fields That Leak Through Relationships
Masking the Contact object cleanly doesn't help if a custom object three relationships away stores the same data in a formula field or a rollup. We see this constantly with custom objects built for loyalty programs, warranty tracking, or service history, where a developer pulled Contact.Email into a formula field for convenience years ago and it's been quietly duplicating unmasked data ever since.
Chatter feed items and attached files are a second leak point. A support agent who pastes a customer's ID card photo into a case comment, or a sales rep who attaches a signed contract with a home address on it, has put PII somewhere your masking tool almost certainly doesn't look. Document and ContentVersion records need their own audit pass, separate from object field masking.
Reports and dashboards saved in a sandbox can also surface unmasked data even after the underlying records are masked, if the report was exported or cached before the masking run completed. Sequencing matters: mask first, then refresh anything downstream that might have cached a snapshot.
Fields You Don't Need to Mask (and Why Over-Masking Breaks Testing)
Not every field with a person's name attached needs scrambling, and treating masking as a blanket exercise creates its own problem. Mask every text field indiscriminately and you'll break picklist-dependent validation rules, flow logic that checks field values, and integration tests that expect realistic formats.
Opportunity.Name, for example, rarely needs masking unless your naming convention embeds a customer ID or deal-specific detail that counts as sensitive. Product and pricing data generally doesn't need it either, since margins and SKUs aren't personal information, even though some compliance checklists flag them out of caution.
Over-masking has a real cost beyond wasted compute. QA teams testing an email validation flow need emails that look real, not strings of random characters that fail every regex check in the org. Masking needs to preserve format and referential integrity: a masked email should still look like an email, a masked phone number should still pass a phone validation rule, and a masked address should still geocode to a real-ish location if your flows depend on it.
Building a Field Inventory Before You Mask Anything
Skip the inventory step and you're guessing. Build it properly and masking becomes a configuration exercise instead of a recurring fire drill. Start with three inputs: a full object and field schema export, a list of all custom objects with their creation dates, and an interview with whoever owns your integration middleware.
Classify every field into one of four buckets:
- Direct identifiers — email, phone, SSN, government ID, full name combinations
- Indirect identifiers — address fragments, date of birth, account numbers that map to a real customer ID
- Free-text risk — description fields, comments, chatter posts, attached files
- Safe to leave — pricing, product data, internal record IDs with no external mapping
Document the owner of each custom object alongside this classification. When a new field gets added mid-year, whoever owns that object should know it needs a masking review before the next sandbox refresh, not six months after an auditor asks about it.
How MaskEzee Handles Field-Level Discovery
MaskEzee was built around the fact that most masking failures are discovery failures, not execution failures. It scans your full schema, including custom objects and fields added after the last masking configuration, and flags fields that match common PII patterns automatically rather than relying on a static rule list someone configured two years ago.
It also handles the relationship-leak problem directly, tracing formula fields and rollups back to their source so a masked Contact.Email doesn't resurface unmasked three objects away on a custom loyalty record. Free-text fields get pattern-matched for embedded emails, phone numbers, and ID formats rather than being skipped because they're not structured fields.
Format-preserving masking keeps validation rules and flow logic intact, so QA teams get data that behaves like production without exposing anything that was actually in production. Pair that with a scheduled schema diff and the field inventory stops being a one-time project and becomes something that updates itself every time someone adds a custom field.
Frequently Asked Questions
Which Salesforce standard fields most commonly get missed during data masking?
Contact and Lead address fields like MailingStreet and MailingPostalCode are frequently left unmasked even when Email and Phone are handled. Case Comments, Description fields, and other long-text areas are also commonly missed because masking tools often target only structured fields, not free text containing pasted customer details.
Do custom fields need the same masking treatment as standard PII fields?
Yes, and they often need more attention because custom fields are rarely documented in a central data dictionary. Fields added by developers or integrations, such as national ID fields or temporary sync payload fields, frequently hold sensitive data that nobody flagged for masking.
Can masking too many fields break sandbox testing?
Yes. Masking fields that do not contain sensitive data, or masking in a way that destroys format, breaks validation rules, flow logic, and integration tests that expect realistic values. Effective masking preserves data shape, so a masked email still looks like an email and a masked phone number still passes format validation.
How often should a Salesforce org re-audit its field inventory for masking?
At minimum twice a year, and ideally every time a sandbox refresh is scheduled. New custom fields, integration changes, and middleware updates regularly introduce new sensitive fields that existing masking configurations will not catch automatically.
Does data masking cover attachments and Chatter posts, not just record fields?
Standard field-level masking tools usually do not touch attachments, ContentVersion records, or Chatter feed items, which means sensitive data pasted into comments or uploaded as documents can remain exposed even after object fields are masked. These need a separate audit and, in many cases, a separate handling process.