Salesforce sandbox masking isn't one policy applied uniformly across an org's sandbox fleet. A Full Copy sandbox holding 3TB of production data needs a fundamentally different masking approach than a Developer sandbox with 150MB of sampled records. Treat them the same and you either burn hours masking data nobody will ever query, or you skip masking on the sandbox that actually gets shared with an offshore QA vendor. The right strategy starts with knowing what each sandbox type actually contains and how often it refreshes.
This matters more than most admins assume. Every Salesforce org runs a mix of Full Copy, Partial Copy, Developer, and Developer Pro sandboxes, and each one carries a different volume of real customer data, a different refresh cadence, and a different audience of people who can log in and see it. GDPR doesn't care which sandbox type leaked data. It cares that unmasked personal data existed somewhere it shouldn't have.
Why Sandbox Type Changes the Masking Math
Salesforce sandbox types differ along three axes that matter directly for masking: storage limit, refresh cadence, and data selection method. Full Copy sandboxes mirror production exactly, byte for byte, including every attachment and history record. Partial Copy sandboxes pull a defined sample using a sandbox template. Developer and Developer Pro sandboxes get metadata plus a small storage allotment, usually populated manually or via a data loader.
Those differences change what "masking" needs to accomplish. In a Full Copy sandbox, the job is volume: millions of Contact and Case records need field-level replacement without blowing past governor limits or turning a four-hour refresh window into a fourteen-hour one. In a Partial Copy sandbox, the job is precision: the sampling logic already decided which records exist, and masking has to catch every one of them, including the ones pulled in through a relationship rule nobody remembers writing.
Developer and Developer Pro sandboxes look low-risk because they're small. They aren't. A single unmasked VIP customer record loaded into a Developer sandbox for a bug reproduction is still a GDPR-relevant exposure, and these are the sandboxes most likely to sit on a contractor's laptop.
Full Copy Sandboxes: Volume Without Excuses
Full Copy sandboxes can run up to 5TB, mirroring every object, every record, every attachment in production. That scale is exactly why so many teams quietly skip masking on Full Copy environments: the refresh already takes hours, and running a masking job afterward feels like adding insult to injury. This is the wrong instinct. Full Copy is the sandbox most likely to get connected to a full-scale performance test, a data migration rehearsal, or an integration sandbox with outbound API calls to third-party tools. Volume is not a reason to skip masking. It's the reason masking has to be efficient.
The practical fix is batch-oriented masking that runs as part of the refresh pipeline rather than as a manual afterthought. Field-level masking rules should be defined once, applied through bulk API calls, and scheduled to trigger automatically the moment a Full Copy refresh completes. Waiting for someone to remember to run masking manually after a quarterly Full Copy refresh is how unmasked data survives for weeks in a sandbox that developers, testers, and consultants are all actively using.
Attachments and files deserve specific attention here too, since Full Copy is the only sandbox type that reliably drags every historical file along with it. Contracts, ID scans, and support ticket screenshots all come across intact unless the masking process explicitly targets file storage, not just database fields.
Partial Copy Sandboxes: The Sampling Trap
Partial Copy sandboxes cap out around 5GB and use a sandbox template to decide which records get included. Admins configure the template once, point it at a few key objects, and assume the resulting dataset is a harmless, random-ish slice of production. It usually isn't random at all.
Sampling rules in a Partial Copy template typically pull records based on recency or relationship, not randomness: the newest 10,000 Accounts, every Case created in the last 90 days, every Contact tied to an included Account. That method has a side effect worth flagging directly: recent records skew toward active, high-value customers, which means the "small sample" a Partial Copy sandbox holds is disproportionately full of the exact customer data most worth protecting. I'd argue Partial Copy is the riskiest sandbox type in most orgs precisely because its small size creates false confidence.
Masking Partial Copy sandboxes has to account for the sampling logic itself. If the template pulls a Contact along with its parent Account and related Opportunities, the masking policy needs to touch all three objects consistently, not just the one the admin remembers configuring. Missing this doesn't just leave a name unmasked. It leaves a name unmasked next to a real email, a real phone number, and a real deal value.
Developer and Developer Pro: Small Data, Same Exposure
Developer sandboxes get roughly 200MB of data storage, Developer Pro around 1GB. Both come with full metadata but essentially no production data unless someone loads it in manually, through a data import wizard, or through an ad hoc SOQL export from another sandbox. That last path is worth sitting with for a second: developers routinely copy a handful of "realistic" records from a Full Copy or Partial Copy sandbox straight into their Developer sandbox to reproduce a bug. If the source sandbox was masked, fine. If it wasn't, the unmasked data just spread to a sandbox with far weaker access controls.
This is the exposure path most masking policies miss entirely, because most masking tools trigger on scheduled refreshes and Developer sandboxes rarely follow a fixed refresh schedule. They get created, used for weeks or months, and refreshed whenever the developer feels like it. A masking policy that only runs on a cron-style refresh trigger simply never touches them.
The fix isn't complicated, but it does require a policy decision: either mask data at the point of manual load into any sandbox, or restrict manual cross-sandbox data copying entirely and route all data population through masked refresh pipelines. Most orgs choose the second option once they see how often the first gets ignored under deadline pressure.
One Masking Policy, Four Sandbox Types
None of this means an org needs four separate masking tools. It means the masking rules need to be defined once, at the field and object level, and then applied consistently regardless of which sandbox type triggers the refresh. The table below is a reasonable starting baseline for most Salesforce orgs running a standard sandbox mix.
| Sandbox Type | Typical Storage | Common Refresh Cadence | Masking Priority |
|---|---|---|---|
| Full Copy | Up to 5TB | Quarterly or biannual | Batch masking of full dataset plus attachments, triggered automatically post-refresh |
| Partial Copy | Up to 5GB | Monthly or on demand | Consistent masking across all objects pulled by the sandbox template, including related records |
| Developer Pro | Up to 1GB | On demand | Masking applied to any manually loaded or copied data, not just scheduled refreshes |
| Developer | Up to 200MB | On demand | Same as Developer Pro; restrict manual PII copy-in as a policy backstop |
The pattern across all four rows is the same: masking has to be triggered by data entering the sandbox, not by a calendar date. Full Copy and Partial Copy refreshes give you a natural trigger point. Developer and Developer Pro sandboxes don't, which is exactly why they need a policy backstop rather than relying on automation alone.
What Breaks When Masking Ignores Sandbox Type
Orgs that apply a single generic masking job across every sandbox type tend to hit one of two failures. Either the Full Copy masking job times out or exceeds API limits because it was designed for a 5GB Partial Copy dataset, or the Developer sandboxes never get touched because the masking automation only listens for scheduled refresh events.
The first failure is loud and gets fixed fast, because a failed masking job on a Full Copy sandbox usually blocks the whole environment from being usable. The second failure is quiet, and that's the dangerous one. A Developer sandbox with unmasked customer data sitting untouched for six months doesn't throw an error. It just sits there, accessible to anyone with a login, until an audit or a breach forces the question of how it got there.
Building masking policy around sandbox type rather than around a single generic job closes both gaps. It also makes audit conversations shorter: instead of explaining a one-size-fits-all masking script, an admin can point to a policy that maps directly to how Salesforce itself defines and provisions each sandbox type.
Frequently Asked Questions
Does a Developer sandbox need the same masking as a Full Copy sandbox?
Yes, though the mechanism differs. Full Copy sandboxes need automated, high-volume masking triggered by scheduled refreshes, while Developer sandboxes need masking applied whenever data is manually loaded or copied in, since they rarely follow a fixed refresh schedule. Skipping masking on a Developer sandbox because it's small still leaves any PII it contains fully exposed.
Why is Partial Copy sandbox masking harder than it looks?
Partial Copy sandbox templates typically sample the most recent or most active records, which means the small dataset is disproportionately made up of high-value, real customer data rather than a random slice of production. Masking has to follow the same relationship rules the template uses, so related Accounts, Contacts, and Opportunities all get masked consistently rather than leaving gaps where one linked object was missed.
How often do Full Copy Salesforce sandboxes need to be masked?
Full Copy sandboxes should be masked immediately after every refresh, not on a separate schedule. Since Full Copy refreshes happen quarterly or biannually in most orgs, masking needs to be part of the automated refresh pipeline so there's no window where unmasked production data sits accessible before a manual masking job gets around to running.
Can attachments and files in a Full Copy sandbox be missed during masking?
Yes, and it happens often because many masking tools focus only on database fields. Full Copy sandboxes carry every historical file and attachment from production, including scanned IDs and support screenshots, so a masking policy needs to explicitly cover file storage, not just object records, to avoid leaving sensitive documents untouched.
What's the biggest masking mistake orgs make across their sandbox fleet?
The most common mistake is applying one generic masking job to every sandbox type regardless of size or refresh cadence. This either causes the job to fail or time out on large Full Copy sandboxes, or leaves Developer and Developer Pro sandboxes untouched entirely because the automation only triggers on scheduled refresh events rather than manual data loads.