Static masking rewrites sensitive values permanently in a sandbox database, so the underlying record is changed at rest and stays changed no matter who queries it. Dynamic masking leaves the real data untouched and hides it only at the moment someone views it, based on their access level. For Salesforce sandboxes, that distinction matters more than most teams realize, because one of these approaches actually removes PII from a copy your developers can export, and the other one doesn't.
I'll say this up front: for full and partial copy sandboxes, static masking is the only option that holds up under an actual audit. Dynamic masking has its place, but it's not a substitute for scrubbing data that leaves production. Let's get into why.
What Static Masking Actually Does
Static masking runs against a sandbox after a refresh, walking through specified fields and replacing real values with realistic fakes. A customer named Sarah Chen becomes a different fictional name. A real SSN becomes a formatted but fake one. Email addresses get rewritten to a domain that can't send or receive live mail.
Once that job finishes, the sandbox database contains no trace of the original values. This is what MaskEzee does on full copy sandboxes: it runs post-refresh, targets the fields you flag as sensitive, and leaves referential integrity intact so a masked Contact still links to its masked Account and its masked Cases.
The key property here is permanence. If a developer exports that sandbox to a CSV, shares a screen recording with an offshore QA team, or connects a third-party test automation tool to it, there's no real PII anywhere in the chain. The masking happened once, at the data layer, and it doesn't depend on who's looking or how they're looking at it.
What Dynamic Masking Actually Does
Dynamic masking works differently. The real data stays in the database exactly as it was copied from production. A masking rule sits between the user and the data, and it decides in real time whether to show the real value or a masked one based on the requesting user's profile or permission set.
Salesforce's own Field-Level Masking (part of Shield Platform Encryption in some configurations, and separately available through Data Detect and related tools) works this way for specific use cases, like hiding a credit card field from a support agent who doesn't need to see the full number. It's fast to set up because there's no batch job rewriting millions of records. You define the rule, assign it to a profile, and it takes effect immediately.
The catch is that the real data never left the building. It's sitting in the sandbox, unmasked, waiting for anyone with sysadmin access, API access, or a Data Loader export to pull it straight out. Dynamic masking controls what a screen shows. It does nothing to control what a query returns.
Where Each One Breaks Down
Static masking has one real weakness: it's a point-in-time job. If you refresh a sandbox and mask it, then someone loads a fresh batch of records from production three weeks later through an integration, those new records arrive unmasked. Static masking has to be re-run or built into your refresh pipeline as a mandatory step, not an optional one someone remembers to click.
Dynamic masking's weakness is more fundamental. It assumes every path to the data goes through the layer that applies the rule. In practice, Salesforce sandboxes get accessed through the UI, through REST and SOAP APIs, through Data Loader, through Workbench, through reporting exports, and through third-party integrations connected for testing. Covering every one of those paths with masking rules is possible in theory and rare in practice. A developer with API access and a query tool can usually pull the raw field regardless of what the page layout shows.
There's also a subtler problem with dynamic masking in a full copy sandbox: performance testing and load testing need real record volumes and real data shapes to be useful, and if your masking layer is intercepting every field read at runtime, you're adding overhead to exactly the tests where overhead skews the results.
Performance and Storage Trade-offs
Static masking costs you time up front, once. A masking job on a large full copy sandbox can run for a while depending on record volume and how many fields and objects are in scope. After that job completes, there's no ongoing performance cost. Queries run against masked data exactly as fast as they'd run against real data, because it's just data.
Dynamic masking costs you a small amount of overhead on every single read, forever, for as long as the sandbox exists. That overhead is usually invisible in day-to-day development. It becomes visible during load tests, bulk data operations, or any process that reads large volumes of records quickly, which happens to be exactly the kind of testing a full copy sandbox exists to support.
Storage-wise, the two are roughly equivalent since dynamic masking doesn't duplicate data. But static masking pairs well with the kind of environment hygiene that actually reduces sandbox bloat over time, since a properly masked sandbox is safe to keep around, snapshot, or clone for parallel dev streams without multiplying your compliance exposure with every copy.
Compliance Considerations: HIPAA, GDPR, SOC 2
Auditors care about where data physically sits, not just what a screen displays. This is the part where dynamic masking tends to fall short of what regulators actually expect.
| Requirement | Static Masking | Dynamic Masking |
|---|---|---|
| Data at rest is de-identified | Yes | No |
| Safe for API/export access | Yes | No |
| Safe for offshore/third-party dev access | Yes | Depends entirely on access controls |
| Setup effort | Higher, one-time per refresh | Lower, rule-based |
| Runtime performance cost | None | Small, on every read |
Under GDPR, the "right to erasure" and general data minimization principles assume that if data isn't needed in a given environment, it shouldn't exist there in identifiable form. A sandbox with real EU citizen data sitting unmasked, protected only by a display-layer rule, doesn't satisfy that. Under HIPAA, the same logic applies to PHI: de-identification standards expect the data itself to be altered, not just hidden from certain viewers. SOC 2 auditors reviewing your change management and data handling controls will ask directly whether non-production environments contain production PII, and "it's masked at the field level for most profiles" is a weaker answer than "the data was rewritten before anyone touched it."
Which One to Actually Use
Dynamic masking earns its keep in production, where you want a support agent to help a customer without seeing their full payment details, but a billing admin can still see everything. That's a legitimate, narrow use case: different visibility for different roles against the same live data.
Sandboxes are a different problem entirely. A sandbox exists so developers, QA, and offshore partners can work against realistic data without production access controls constantly getting in the way. Layering dynamic masking rules on top of a sandbox just recreates production's access complexity in an environment that's supposed to be simpler to work in, while still leaving the real data exposed to anyone who routes around the rule.
Our position, and the reason MaskEzee is built around static masking, is straightforward: for any sandbox that leaves your direct control, even briefly, the safest assumption is that someone will eventually query it directly. Static masking makes that scenario a non-event. Dynamic masking makes it a data breach.
Frequently Asked Questions
Is dynamic data masking ever appropriate for a Salesforce sandbox?
It can work for narrow, controlled cases where you only need to hide specific fields from specific internal roles and you're confident no one has direct API or export access. In most full and partial copy sandboxes used for development or QA, that confidence doesn't hold, since Data Loader, Workbench, and integration users typically bypass display-layer rules. For anything shared with offshore teams, contractors, or third-party testing tools, static masking is the safer default.
Does static masking break record relationships in a sandbox?
Not if the masking tool is built to handle referential integrity, which means it masks linked fields consistently across related objects. A masked Contact should still point to the correct masked Account, and a masked Case should still reference the correct masked Contact. Tools like MaskEzee are designed specifically to preserve those relationships so the sandbox still behaves like a real, connected dataset after masking.
How long does static masking take to run on a full copy sandbox?
It depends on record volume, the number of objects and fields in scope, and how the masking job is configured, but it typically runs as part of the post-refresh process rather than as a separate manual step. Larger orgs with millions of records will see longer run times than smaller ones. The tradeoff is a one-time cost per refresh in exchange for zero ongoing performance impact, unlike dynamic masking which adds overhead to every query indefinitely.
Can dynamic masking satisfy GDPR or HIPAA requirements on its own?
Generally no, because both frameworks focus on whether identifiable data physically exists in a given environment, not just whether it's visible on a screen. Dynamic masking leaves the raw data intact in the database, which means anyone with query or export access can retrieve it regardless of the masking rule. Auditors reviewing non-production environments typically expect data to be de-identified at rest, which is what static masking provides.
What's the difference between data masking and data encryption in a sandbox?
Encryption protects data from unauthorized access outside the system, typically at the storage or transport level, but authorized users with proper decryption keys or platform access can still see the real values. Masking changes or hides the actual values so even authorized sandbox users never see real production data. The two solve different problems and are often used together, but encryption alone does not make a sandbox safe for broad development or QA access.