Salesforce platform change
Salesforce Data Mask reaches end of service on December 31, 2026
The Data Mask managed package is being retired — not masking itself. Here is what is actually changing, what Salesforce recommends instead, and what your options are if you mask sandbox data today.
“The Data Mask managed package reaches end of service on December 31, 2026. After this date, Salesforce no longer supports the Data Mask managed package. To continue protecting your sandbox data, start working with Data Mask & Seed before December 31, 2026.”
— Salesforce Help: Secure Your Sandbox Data with Salesforce Data Mask (Legacy)
Salesforce documentation last checked .
What is actually changing
Salesforce Data Mask was delivered as a managed package that you installed into your production org and ran against your sandboxes. That package is what reaches end of service. Salesforce has since renamed its documentation to “Salesforce Data Mask (Legacy)” and points customers at Data Mask & Seed, which is built into the platform instead of installed as a package.
So this is not a capability being withdrawn. It is a re-platforming, and the practical consequence for you is that the masking configuration you built has to be re-created and re-validated in something else before the deadline.
That re-validation is the part worth taking seriously. A masking rule that quietly stops matching a field does not throw an error — it just leaves real customer data sitting in a sandbox that a dozen people can open. If you are migrating masking configuration, the deliverable is not “the jobs run”, it is “these named fields are demonstrably masked”.
Your three options
We sell one of these. We have tried to describe all three fairly — you can check every claim about the Salesforce products against the links above.
Move to Data Mask & Seed
The path Salesforce recommends, and the lowest-surprise option if you are happy with how Data Mask worked. It is native, it adds seeding, and it stays inside the Salesforce relationship you already have. Ask your AE what your existing Data Mask entitlement converts to.
Salesforce's recommendationEvaluate an AppExchange alternative
Reasonable specifically because you have to redo the configuration work regardless. The switching cost you would normally weigh against changing tools is a cost you are paying either way, which makes this the one moment where a real comparison is close to free.
Worth doing now, not in 2027Do nothing yet
Defensible only if you know how much masking you actually have. If nobody can currently say which fields are masked in which sandboxes, that is not a decision to defer — it is an open compliance question you happen to have a deadline attached to.
Only with eyes openData Mask (Legacy) vs Data Mask & Seed vs DataMasker
Salesforce columns reflect Salesforce's published documentation. Neither Salesforce product has publicly listed pricing, so those cells say so rather than guess.
| Data Mask (Legacy) | Data Mask & Seed | CC DataMasker | |
|---|---|---|---|
| Status after 31 Dec 2026 | End of service — no longer supported | Salesforce's current masking product | Unaffected |
| How it is delivered | Managed package installed in your production org | Built into the Salesforce platform | Managed package from AppExchange |
| Where masking runs | Inside your Salesforce org | Inside your Salesforce org | Inside your Salesforce org |
| Licensing | Salesforce Data Mask managed package (Legacy) add-on licence | Salesforce Data Mask add-on licence | Per-org subscription |
| Published pricing | Not publicly listed | Not publicly listed | Listed on our pricing page |
| Run on sandbox refresh | Yes | Yes — manual, scheduled, or automatically on create/refresh | Yes |
| Reusable masking configuration | Data Mask configurations | Reusable masking policies | Reusable masking rules |
| Custom replacement values | Custom libraries | Built-in and custom replacement value libraries | Built-in and custom patterns |
| Filter which records get masked | Limited | Yes — per object | Yes — per object and field |
| Preserves production record IDs | Yes — masks in place | Yes — masks in place | Yes — masks in place |
| Synthetic data seeding | No | Yes — seeding is part of the product | No — masking only, by design |
| Runs from a DevOps pipeline | Limited | See Salesforce documentation | Yes — Copado and other CI/CD tools |
A migration plan that fits the time left
- Now
Find out whether you are affected
Check whether the Data Mask managed package is installed in your production org, and which sandboxes actually run masking jobs against it. Teams are frequently surprised here — masking is often set up once and never revisited.
- Next
Write down what your current masking actually does
Export your existing configurations: which objects, which fields, which replacement values. This is the artefact you migrate, and it is also the checklist you validate against afterwards. Do this before you touch any new tool.
- Then
Pilot the replacement on one sandbox
Whichever product you choose, run it against a single non-critical sandbox and diff the result against your written configuration. Confirm field by field that what should be masked is masked.
- Before 31 Dec 2026
Cut over and decommission
Move the remaining sandboxes, confirm masking runs on refresh, and remove the legacy package once nothing depends on it. Leaving an unsupported package installed is its own audit finding.
Data Mask end of service: common questions
Working out what to do before December 2026?
We will walk your masking configuration with you and tell you plainly whether moving to Data Mask & Seed or to DataMasker is the better fit for your org. No obligation to switch.