Most Salesforce masking tools scan standard and custom object records. Custom Settings and Custom Metadata Types rarely make that list, which is a problem because both frequently store real names, emails, and phone numbers hardcoded by admins years ago. A masking job can run clean, every Contact and Lead scrubbed, and a support team's live distribution list still sits untouched in a Hierarchy Custom Setting that nobody remembers exists.
This gap is not a bug in your masking tool. It is a scope decision, and most vendors made it years before Custom Metadata Types became a standard part of Salesforce configuration. The result is a blind spot that has quietly grown as orgs shifted more and more logic, and more and more hardcoded values, into these declarative layers.
Why Configuration Data Falls Outside Standard Masking Scope
Masking engines are built around object schemas. They read field metadata for Account, Contact, Case, and custom objects, then apply substitution rules row by row. Custom Settings and Custom Metadata Types technically live in the metadata layer, not the data layer, so many tools never enumerate them as maskable targets at all.
That distinction matters to a query optimizer. It does not matter to GDPR. A phone number stored in a List Custom Setting record is exactly as identifiable as one stored in a Contact record, and a sandbox that copies it during a full or partial refresh has exposed real personal data regardless of which table it lives in.
Admins compound the problem by treating Custom Settings as configuration rather than data. Nobody runs a PII audit against them because nobody thinks of them as a place PII would end up. Yet escalation contacts, approval routing emails, and support team rosters get stored there constantly, usually because a developer needed a quick way to reference a value without building a full custom object.
Where the Real PII Actually Hides
Once you start looking, the pattern is consistent across orgs. The same handful of use cases keep reintroducing real personal data into configuration records.
- Hierarchy Custom Settings storing a named approver's email for escalation notifications, often set per profile or per role
- List Custom Settings holding regional support contact phone numbers used in Flow or Apex notification logic
- Custom Metadata Type records that map territories or business units to named account owners and their direct emails
- Integration configuration records storing a named technical contact's email for callback or error alerting
- Custom Settings fields used as fallback values in formula fields or Flow decision elements, referencing a specific person's contact details
None of these fields are labeled "PII" in the schema. They are text or email fields on configuration objects, which is exactly why standard masking rules skip them. A masking policy built purely on field-level naming conventions, like flagging anything named Email__c, will still miss values buried in generic Value__c fields on a Custom Metadata Type.
Why This Is a Compliance Problem, Not Just a Cleanliness Issue
Sandboxes get shared broadly. Developers, QA contractors, and offshore teams routinely get access to full or partial copy sandboxes that include every Custom Setting and Custom Metadata record from production. If those records contain a real manager's email or a named employee's direct phone number, that data has now reached people with no legitimate business reason to see it.
Article 32 of GDPR requires appropriate technical measures to protect personal data, and that requirement does not carve out an exception for data stored in configuration objects instead of standard objects. An auditor asking "where does personal data live in your sandbox environments" is not going to accept "only in the objects our masking tool covers" as a complete answer.
Change sets and metadata deployments make this worse. Custom Settings and Custom Metadata records travel with deployments between orgs, including from production down to sandboxes during environment builds, which means the same hardcoded PII can end up replicated across every lower environment your team maintains. I've seen orgs with a single hardcoded escalation email sitting in six different sandboxes, none of them ever touched by a masking run.
How Configuration-Aware Masking Closes the Gap
Closing this gap requires treating Custom Settings and Custom Metadata Types as maskable data sources, not just deployable metadata. That means enumerating their fields the same way you enumerate object fields, then applying substitution rules to any field holding a name, email, or phone value.
| Data Source | Typical Coverage by Standard Masking Tools | Common PII Found |
|---|---|---|
| Standard/custom objects | Full coverage, primary target | Names, emails, phones, addresses |
| List Custom Settings | Rarely scanned | Support emails, regional phone numbers |
| Hierarchy Custom Settings | Almost never scanned | Approver emails by profile or role |
| Custom Metadata Types | Inconsistent, tool-dependent | Named contacts in routing and mapping records |
MaskEzee treats these configuration records as first-class masking targets, applying the same field-level rule engine used on standard objects to List Custom Settings, Hierarchy Custom Settings, and Custom Metadata Type records. Fields get classified by content pattern, not just by label, so a generic Value__c field holding an email address still gets caught and replaced with realistic fake data before the sandbox becomes accessible.
A Remediation Checklist Worth Running This Quarter
Fixing this does not require a rebuild of your masking process. It requires extending the inventory you already have to a layer most teams have never audited.
- Export a full list of Custom Settings and Custom Metadata Types from production, including field-level definitions
- Flag any text, email, or phone field whose current values include real names, emails, or numbers
- Cross-reference flagged fields against Flow, Apex, and validation rule logic that reads them, to confirm masking a value will not silently break routing
- Add masking rules for confirmed PII fields, using consistent fake-but-realistic substitution rather than blank values, so downstream logic still functions in the sandbox
- Re-run a full sandbox refresh and manually spot-check three or four Custom Setting and Custom Metadata records post-mask
That last step matters more than it sounds. A masking rule that passes validation in isolation can still fail silently on a Hierarchy Custom Setting if the rule engine does not correctly resolve per-profile or per-role record variants.
Keep the Inventory Current
The harder part is not the initial cleanup. It is keeping the inventory current as admins add new Custom Metadata Types for every new integration or business rule. Each new type is a potential new PII surface, and most orgs have no process that automatically flags it for masking review.
Build the check into your release process instead of treating it as a one-time audit. Any new Custom Setting or Custom Metadata Type with a text, email, or phone field should trigger a quick classification step before it ships to production, the same way a new custom field on Contact would. Configuration data ages the same way object data does, and if nobody owns the review, it quietly becomes the next blind spot your masking policy forgot about.
Frequently Asked Questions
Do Salesforce Custom Settings actually contain personal data?
Yes, frequently. Admins commonly hardcode named approvers' emails in Hierarchy Custom Settings and regional support phone numbers in List Custom Settings to support Flow and Apex logic. These values are real personal data and copy over during sandbox refreshes just like standard object records.
Why don't most masking tools cover Custom Metadata Types?
Most masking engines were built to scan object schemas for standard and custom objects, treating Custom Metadata Types as deployable metadata rather than maskable data. This scoping decision predates the widespread use of Custom Metadata Types for storing configuration values that include personal information.
Can masking Custom Settings break Flow or Apex logic?
It can if the masking rule replaces a value that logic depends on for routing decisions rather than display. The safer approach is to cross-reference flagged fields against Flow and Apex before masking, then substitute realistic fake values instead of blanking fields so downstream logic keeps functioning.
Does GDPR Article 32 apply to data stored in Custom Settings?
Yes. Article 32 requires appropriate technical safeguards for personal data regardless of which Salesforce object or metadata type stores it. A sandbox containing an unmasked real email in a Custom Setting record is exposed personal data whether or not it sits in a standard object.
How does MaskEzee handle Custom Metadata Type records?
MaskEzee applies its field-level rule engine to List Custom Settings, Hierarchy Custom Settings, and Custom Metadata Type records the same way it does to standard and custom objects. Fields get classified by content pattern rather than field label alone, so generic fields holding emails or phone numbers still get caught and replaced.