Salesforce Data Mask & Seed is the built-in replacement for the retired Data Mask managed package, and Salesforce publishes a page listing exactly what it does not do: it masks only three types of User record, above 20 million records it stops preserving data distributions and cross-object consistency, it caps jobs at 350 million records and 12 per sandbox per day, and it does not bypass automations or Duplicate Detection when deleting. This article goes through each limit, what it means for a real sandbox, and what to check before you build a masking programme on it.
What changed, and what it costs
Two facts first, because a lot of coverage gets them wrong.
The old package is already unsupported. Salesforce's knowledge article states that support for the Data Mask managed package ended on 9 July 2026 and that the package becomes read-only on 31 December 2026. If you are still running it, you are running software Salesforce will not fix. The full picture — including the older product page that still says "end of service 31 December" — is on our Data Mask end-of-service page.
The replacement is built in, but not free. Data Mask & Seed has been available since the Summer '26 release (18 July 2026) as a Core application — nothing to install from AppExchange. Salesforce's documentation lists it as available in Professional, Enterprise, Unlimited and Developer Editions with the Salesforce Data Mask add-on license, and each user needs the "Data Mask And Seed User" permission set licence. Salesforce does not publish a price. Whether your existing Data Mask entitlement carries across is a question for your account executive; ask it explicitly.
What Data Mask & Seed does
Credit where it is due. Per Salesforce's documentation, the new app provides reusable masking policies; built-in and custom replacement-value libraries, with an Einstein option to generate library entries; masking jobs that run manually, on a schedule, or automatically when a sandbox is created or refreshed; per-object record filters; job monitoring with a report per job; and seeding — populating a sandbox with generated records; the knowledge article describes Data Cloud seeding and AI seeding being integrated into the same interface. For an org that refreshes a couple of sandboxes a quarter and needs names, emails and phone numbers replaced with plausible values, that is a real product, and it is the one Salesforce will keep investing in.
The question is what happens at the edges. Salesforce answers it on a page titled "Data Mask & Seed Requirements and Limitations". Here is that page, translated into consequences.
The seven documented limitations
| # | What Salesforce documents | What it means in a sandbox |
|---|---|---|
| 1 | When the User object is in a policy, only three user types are masked: PowerCustomerSuccess, CustomerSuccess and CspLitePortal | Internal user records — employees' names and emails — are not masked by the User-object policy |
| 2 | Above 20,000,000 records in a job, the app "doesn't preserve existing data distributions" and "doesn't apply consistent field masking across objects" | Large jobs lose two properties testers rely on: value frequencies that look like production, and the same masked value for the same person's email on Contact and on Lead |
| 3 | A job is capped at 350,000,000 records; if the count exceeds it, the job is cancelled and nothing is masked | Very large orgs must split policies by object or filter records before anything runs |
| 4 | Maximum 12 masking jobs per sandbox in a rolling 24-hour window; further jobs are cancelled | Iterating on a policy — run, check, adjust, run — has a daily budget |
| 5 | Deleting Feed Items and History records, and PII-bearing Case Comments, Email Messages and Chatter Comments, "doesn't bypass automations" | Triggers, flows and validation rules fire on those deletes; expect failures and side-effects in orgs with heavy automation |
| 6 | Duplicate Detection is not bypassed: "duplicates may be created, unless the user manually disables the automation before the masking job" | A manual step before and after every job, or masked records that trip duplicate rules |
| 7 | The Einstein option for generating custom-library entries needs an Einstein licence, and each generation is limited to 100 entries | Building a large custom library is either manual or many small generations |
And one more from the knowledge article rather than the limitations page: masking policies from the managed package are not migrated. "New functionality is only available through newly created policies." Custom libraries do carry across; the policies you spent months tuning do not.
None of these are hidden. They are the first things Salesforce tells you to read. They are also the reason a masking programme built on the assumption "it's built in, so it's handled" gets a surprise the first time a refreshed sandbox emails a real customer.
What it was never built to do
The documented limits are about masking. The gaps that actually cause incidents are around masking, and no built-in tool addresses them because they are not masking problems.
A refreshed sandbox does more than hold data. It holds active email addresses, live remote-site settings, scheduled jobs and integration endpoints copied from production. Masking the Email field does nothing about the workflow that fires on record update and the remote site that still points at a live payment gateway. The single best-performing article on this site is about exactly that failure — a sandbox refresh that sent real emails to real customers. DataMasker treats post-refresh cleanup as part of the masking job: it auto-updates remote-site settings and custom labels, and deletes files, case comments and tasks that carry production content.
Masking has to fit the release process, not sit beside it. Salesforce's documentation describes running jobs from the app, manually or on a schedule, or automatically when a sandbox is created or refreshed. It does not describe triggering a job from outside the app. If your sandboxes are created by a pipeline, the masking step has to be callable from that pipeline. DataMasker exposes an API so masking runs from DevOps tooling as a step, with the result logged, rather than as a reminder to click something afterwards.
Some fields need logic, not a lookup. A custom encrypted field that has to be decrypted before it can be masked; a national ID with a checksum; a value that must match a pattern a downstream system validates. Library substitution cannot express those. DataMasker supports custom Apex classes, regular expressions and lookup substitution lists inside a masking rule.
Scale changes the guarantees. The 20-million-record threshold is where Data Mask & Seed stops promising consistent masking across objects. DataMasker masks in place, so record IDs and parent–child relationships are preserved by construction rather than by a consistency pass; it sustains three to five million records per hour, has masked 99 million records in 24 hours, and its largest published deployment is 165 million records for an insurance customer — read that case study.
When the built-in tool is enough
Be honest with yourself about which column you are in.
Data Mask & Seed is probably enough if: you refresh a small number of sandboxes on a predictable cadence; your masking jobs stay well under 20 million records; nobody expects consistent masked values across objects; your sandboxes are created by hand, not by a pipeline; your automation on Feed, History and comment objects is light; and you have a documented post-refresh checklist that someone actually runs.
You need a purpose-built tool if: any sandbox is created by CI/CD; testers depend on realistic distributions or cross-object consistency; you have custom encrypted fields or format-validated identifiers; a refresh has ever sent an email or hit an endpoint it should not have; or you have more than a dozen masking runs a day across your estate.
Neither answer is embarrassing. The wrong answer is not asking.
Migrating off the managed package either way
Whichever you choose, the managed package is read-only on 31 December. Policies do not migrate to Data Mask & Seed and they do not migrate to anything else; they are re-created. That makes this the one moment where switching tools costs nothing extra — the configuration work is being redone regardless. The end-of-service page has the three-way comparison and a migration plan; the masking-vs-seeding page answers the cost and "what is the difference" questions.
Run the re-validation before you switch anything off. A masking rule that quietly stops matching a field does not throw an error. It leaves real data in a sandbox that a dozen people can open.
The short version
Data Mask & Seed is a real product, built in, not free, and documented honestly — seven limitations on one page, including a 20-million-record threshold where consistency guarantees end, a 12-jobs-a-day cap, and no automation bypass on deletes. It does not do post-refresh cleanup, pipeline-triggered masking, or custom masking logic, because it was not built to. Decide which column you are in before 31 December, because you are re-creating your policies either way.
Sources
- Salesforce Help, Data Mask & Seed Requirements and Limitations (help.salesforce.com, read 18 September 2026)
- Salesforce Help, Data Mask Managed Package End of Support, knowledge article 005299299, updated 4 August 2026
- Salesforce Help, Protect Sensitive Data with Data Mask & Seed — required editions and licence
- Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy)
- Cloud Compliance product pages: Sandbox DataMasker, DataMasker vs data seeding, Data Mask end of service
Frequently Asked Questions
No. Salesforce's documentation lists it as available in Professional, Enterprise, Unlimited and Developer Editions with the Salesforce Data Mask add-on licence, and users need the Data Mask And Seed User permission set licence. It requires no installation — it is a Core application — but "no installation" is not "no licence". Salesforce does not publish the price.
Salesforce documents seven: only three User types are masked; above 20 million records a job no longer preserves data distributions or masks identical fields consistently across objects; jobs are capped at 350 million records; a sandbox can run at most 12 masking jobs in 24 hours; deleting Feed, History, Case Comment, Email Message and Chatter Comment records does not bypass automations; Duplicate Detection is not bypassed; and Einstein-generated library entries need an Einstein licence and come 100 at a time. Policies from the old managed package are not migrated.
Per Salesforce's documentation, when the User object is included in a masking policy, only PowerCustomerSuccess, CustomerSuccess and CspLitePortal user types are masked — community and portal users, not internal employee records.
Salesforce's documentation describes running masking jobs from the app manually, on a schedule, or automatically on sandbox creation or refresh. It does not describe an external trigger. If masking must be a step in a pipeline, check for an API before you commit to the design.
No. Salesforce's knowledge article says new functionality is only available through newly created policies; custom libraries do not require migration but policies are re-created in the new app.
Post-refresh cleanup as part of the job (remote-site settings, custom labels, files, case comments, tasks); masking triggered from a DevOps pipeline through an API; custom masking logic with Apex, regular expressions and substitution lists; and in-place masking that preserves record IDs and parent–child relationships at any volume, sustained at three to five million records per hour. It is a masking tool — it does not seed synthetic records.
Related Resources
How to Evaluate Salesforce Data Masking Tools: 12 Criteria That Matter
What Is Data Anonymization?
Anonymization is the only technique that takes data out of GDPR scope entirely. It is also the hardest to achieve, because relational data re-identifies itself through quasi-identifiers. Most teams who believe they anonymized their data actually pseudonymized it.
What Is Pseudonymization?
Pseudonymization replaces identifying values with substitutes while keeping re-identification possible using information held separately. That last part is why pseudonymized data stays in scope for GDPR, and why teams who think they have anonymized their sandbox usually have not.
Keeping Salesforce AI Compliant: The Privacy Gaps the Einstein Trust Layer Leaves Open
Agentforce and Einstein create privacy risks the Trust Layer only partly covers. See the DSAR, consent, and retention gaps and how to close them.
165M+ Records masked in Salesforce Sandbox with DataMasker
See how a major life insurer in Australia and New Zealand masked 165M+ records in Salesforce Sandbox in under 24 hours.
Learn More About Cloud Compliance
Explore our native Salesforce data privacy products.