In one sentence: a sandbox refreshed from production contains real customer data with weaker controls and more people in it, so the data must be altered before anyone uses the sandbox, and Salesforce Data Mask is the supported way to do that. Whatever route you take, masking is irreversible by design, it runs after the refresh rather than during it, and the window between the refresh completing and the mask finishing is the risk you are managing.
Why this is a real problem and not a policy box
Full and partial copy sandboxes contain production records. Sandbox users typically include contractors, implementation partners and developers who would never be granted production access. Sandbox data can be exported without the controls production has. And sandboxes send email, which is how a test flow ends up mailing 30,000 real customers from a system labelled UAT.
The email one is worth handling on day one, separately from masking. Sandboxes default to restricted email deliverability, and the mistake is turning it up to All Email for a test and leaving it there.
Salesforce Data Mask
Data Mask is a managed package installed into production and run from the sandbox. You build a configuration listing objects and fields, choose a masking technique per field, and run it. The masking happens in place in the sandbox, and there is no undo.
The techniques available cover the usual needs:
- Replace from a library of realistic values, so names look like names and addresses look like addresses. Important for anything users will demo or test against.
- Pattern-based replacement, so a masked value still matches a format your validation rules accept.
- Delete, which empties the field entirely.
Two operational points. It runs as an asynchronous job over your data volume, so on a full copy sandbox it takes hours, not minutes. And it can be triggered automatically after a refresh through a sandbox post-copy Apex class, which is the only way to close the gap between the sandbox becoming available and the data being safe. Do that. A manual step performed by whoever is around on the day is not a control.
Data Mask is licensed separately from the core platform, and what your org is entitled to depends on your agreement. Check before you plan around it.
Doing it yourself
A hand-rolled masking job is a batch Apex class that overwrites fields with generated values. It is entirely feasible and people underestimate it for three reasons.
The masking write has to get past your own validation rules, required fields, duplicate rules and triggers, all of which fire. You end up disabling automation in the sandbox to mask it, which is its own risk. Referential consistency is hard: the same customer appearing on an account, three contacts and a case should mask to the same fake name, or your test data stops making sense. And the job has to be maintained forever, because every new field holding personal data must be added to it, and nobody remembers.
DIY is reasonable for a small org with a handful of sensitive fields and a partial copy sandbox.
What must be masked, and what merely should be
Must. Anything that identifies a person or would cause harm if it leaked: names, email addresses, phone numbers, postal addresses, dates of birth, national identifiers, bank details, health information, and free text fields such as case descriptions and notes, which are where sensitive data actually hides. Also API keys and endpoints stored in custom settings or custom metadata, which are not personal data but are a live route into another system.
Should, with judgement. Commercial data such as opportunity amounts, contract terms and pipeline. It is not personal data, so the legal requirement is usually absent, but a sandbox with the real forecast in it is a leak waiting to happen. Mask it if partners have access.
Leave alone. Reference and configuration data, product catalogues, picklist-driven fields, and anything the system’s behaviour depends on. Masking a country code or a record type breaks the sandbox and teaches everyone that masking is an obstacle.
Build the list from a field inventory rather than from memory, and review it whenever new fields ship. The field that leaks is always the one added last quarter.
Frequently asked
Can I mask production data? No, and you should not want to. Masking is destructive and production is the source of truth.
Does a partial copy sandbox need masking? Yes. A sample of real customer records is still real customer records.
What about developer sandboxes? They contain no production data by default, so the risk is whatever someone loads into them. Which is frequently a production export, so the policy needs to cover it.
