Static data masking permanently rewrites PII in a copy of your data, so the fake values persist everywhere that copy lives. Dynamic data masking hides the real values at query time, based on who's asking, while the underlying record stays untouched. For Salesforce sandboxes, that distinction is not academic. It determines whether a QA contractor, a bad SOQL query, or a stray API integration can pull a real customer's phone number out of a system you thought was safe.
Salesforce sells both, sort of. Shield Platform Encryption and field-level security get marketed alongside masking language, and vendors blur the terms further. Before picking a tool or a policy, it helps to separate what static and dynamic masking actually do, and where each one belongs in a Salesforce org.
What separates static masking from dynamic masking
Static masking runs once, before or during a sandbox refresh. It reads every record, replaces names, emails, phone numbers, and custom PII fields with realistic fake values, and writes those values back to the database. After that job finishes, the real data is gone from that environment. There's no real value left to leak, because it was never stored there in the first place.
Dynamic masking works differently. The real data stays in place, usually in production or in a database sitting behind an application layer. A masking rule intercepts each query and decides, based on the user's role or permission set, whether to return the real value or a substituted one. An admin might see the full record. A support rep might see a truncated card number. The record itself never changes.
Both approaches reduce exposure. Only one of them actually removes the PII from the environment.
Why Salesforce sandboxes almost always need static masking
Sandboxes are copies. A full or partial copy sandbox duplicates entire tables of production data, including every custom object your teams have built to store account numbers, health details, or HR records. That copy sits on Salesforce's infrastructure, gets accessed by developers, QA testers, and often outside contractors, and frequently gets exported to CSV for a debugging session that never gets cleaned up.
Dynamic masking can't help here, because it depends on intercepting live queries against a single source of truth. A sandbox isn't that. It's a full duplicate, and anyone with API access, Data Loader, or basic SOQL can bypass a query-time rule and read the raw table. If a developer runs an ad hoc Apex script in a sandbox, dynamic masking rules built for the UI layer generally don't apply.
This is the core reason CloudEzee built MaskEzee around static masking. It runs before every refresh, rewrites PII in the sandbox itself, and leaves nothing sensitive behind for a query, an export, or a careless integration to expose. The data is fake at rest, not just fake on screen.
Where dynamic masking still earns its place
None of this makes dynamic masking useless. It solves a different problem: limiting exposure in a live, single-copy system where the real data has to stay real for business operations to function. A production support queue where agents need to verify the last four digits of a card, but not the full number, is a textbook dynamic masking use case. Shield Platform Encryption's field-level masking in list views works the same way for production users who need partial visibility.
The mistake is assuming that because dynamic masking protects production users from seeing full PII, it also protects a sandbox copy of that data. It doesn't. Once a full copy sandbox is created, the encrypted or masked-at-query-time fields are refreshed as encrypted ciphertext or as whatever the underlying storage actually holds, and depending on configuration, that can still include recoverable PII if key management or field history tracking wasn't scoped correctly.
The compliance gap dynamic-only masking leaves behind
Under GDPR, a sandbox with real customer data is processing personal data, full stop. Article 32 requires appropriate technical measures, and regulators have been consistent that pseudonymization applied only in the production UI does not extend to downstream copies. If your sandbox refresh process copies live data and your masking strategy is entirely dynamic, every refresh recreates a new, unprotected copy of regulated PII.
I've seen this exact gap in audits: a company had airtight dynamic masking rules in production, felt confident about their GDPR posture, and had never touched their sandbox refresh pipeline. Three sandboxes, refreshed monthly, sat with unmasked customer records for years. The dynamic rules never applied there because sandboxes don't inherit production's query-layer permission logic in the way people assume.
That's the audit finding that gets a Salesforce admin a very uncomfortable meeting. Static masking closes it, because the fake data becomes the only data that exists in the sandbox, regardless of who queries it or how.
Choosing an approach: a practical breakdown
| Factor | Static masking | Dynamic masking |
|---|---|---|
| Where it applies | Sandboxes, backups, data exports | Live production queries |
| PII in storage | Removed permanently | Remains, hidden at query time |
| Protects against API/SOQL bypass | Yes | Depends on rule scope |
| GDPR sandbox coverage | Direct | Indirect at best |
| Performance overhead | One-time, at refresh | Ongoing, per query |
Most Salesforce orgs need both, applied to different layers. Dynamic masking for production users who need partial visibility. Static masking for every non-production copy, applied automatically on every refresh so nobody has to remember to run it manually.
Implementation pitfalls worth avoiding
The most common failure isn't picking the wrong approach, it's picking the right one and applying it inconsistently. A static masking job that only covers standard fields like Contact.Email and Account.Phone will miss the custom fields your business actually built to store sensitive data: national ID numbers, medical notes, salary history. Those live in custom objects that a generic masking tool often doesn't know to scan.
Referential integrity is another trap. Masking a customer's name in the Contact record but leaving the same name unmasked in a related Case description or an attached PDF defeats the purpose. A masking job needs to run consistently across every object that touches the same identity, not field by field in isolation.
Finally, timing matters more than most teams think. Masking that happens after a sandbox refresh, rather than as an inline step in the refresh pipeline, leaves a window where real data sits exposed. Even a few hours is enough for a scheduled integration job to pull unmasked records into a downstream system. Static masking belongs in the refresh pipeline itself, not as a cleanup task someone remembers to trigger afterward.
Frequently Asked Questions
Is Salesforce Shield Platform Encryption the same as data masking?
No. Shield Platform Encryption encrypts data at rest using keys you control, but authorized users with the right permissions can still view the decrypted value. Data masking replaces the real value with a fake one, so there is no original value left to decrypt or view. They solve different problems and are often used together in production, but encryption alone does not satisfy masking requirements for sandboxes.
Can dynamic data masking protect a Salesforce sandbox?
Generally, no. Dynamic masking depends on intercepting queries against a single live data source based on user permissions, and a Salesforce sandbox is a separate duplicated copy of that data. Once a full or partial copy sandbox is created, the dynamic rules applied in production do not automatically carry over to protect direct SOQL queries or Data Loader exports in the sandbox.
Does static masking break Salesforce automation and testing?
Well-built static masking preserves data formats, relationships, and referential integrity, so validation rules, flows, and Apex tests continue to work against realistic-looking data. Problems only arise when a masking tool changes data types, breaks foreign key relationships between related records, or ignores custom fields that automation depends on. Testing your masking rules against a sample refresh before rolling them out org-wide catches these issues early.
How often should Salesforce sandbox masking run?
Masking should run every single time a sandbox is refreshed, not on a separate manual schedule. Any refresh that pulls from production reintroduces real PII into the sandbox, so masking needs to be built into the refresh pipeline itself as an automatic step. Relying on someone to remember to run a masking job afterward is how unmasked data ends up sitting in a sandbox for weeks or months.
What PII do teams most often forget to mask in Salesforce?
Custom fields on custom objects are the most commonly missed category, since generic masking tools default to standard fields like Email and Phone. Attachments, Chatter posts, and rich text fields containing pasted customer details also frequently escape masking scans. A thorough masking policy needs to inventory every object and field type that can hold personal data, not just the obvious standard ones.