Syntharil masks personal data automatically as it copies records into your sandbox — deterministically, so your test org stays realistic and referentially consistent without holding a single real customer value.
Sandboxes are copied more freely and accessed by more people than production, so raw customer PII sitting in them is a standing breach-and-compliance risk. Masking removes real names, emails, phone numbers, and identifiers so a leaked sandbox or a stray test email can never expose a real person.
Email, phone, and SSN/Tax-ID fields are recognised automatically; you can mark any other field for masking.
Each value is replaced using a deterministic transform — the same input always maps to the same masked output.
The target org receives only masked values. Masking happens in transit, as part of the copy.
Replaced with a deterministic fake address on a masked domain — syntharil-masked.com by default, or a custom domain you set.
Swapped for a realistic fake number in the same format.
Detected and replaced with a format-valid fake identifier.
Rewritten to a harmless placeholder URL.
Each letter and digit is replaced (letters stay letters, digits stay digits), preserving case, punctuation, and length.
Value blanked or replaced with a fixed token.
Keeps the first and last character and stars out the middle.
Digits randomised while the field stays numeric.
Deterministic masking maps the same input to the same output every time. That means a Contact’s masked email still matches the same email wherever it appears — on related Cases, EmailMessages, or any custom object — so foreign keys and cross-object joins keep working after masking. Random, non-deterministic replacement breaks those relationships.
| Consideration | Masking after a refresh | Syntharil (during the copy) |
|---|---|---|
| When masking runs | After production data has already landed in the sandbox | In transit, as records are copied — the target only ever receives masked values |
| Relationship consistency | Non-deterministic replacement can break cross-object joins | Deterministic — the same value maps the same way everywhere, so joins stay valid |
| Which org it runs in | Inside the freshly refreshed sandbox | Into any org you already control, over the API |
| Field coverage | Configured per masking policy | Auto-detects email, phone, and SSN/Tax-ID; eight styles, configurable per field |
| Preview | Inspect after the run | Live Masking Playground preview before you run |
Before you run a copy, the Masking Playground shows exactly how a value will be transformed — so you can confirm the masking is right without touching a real sandbox.
Deciding how to keep PII out of your sandboxes? Read How to mask PII in Salesforce sandboxes →, or see how masking powers replication →. Comparing tools? See masking tools compared →.
Yes. Email, phone, and SSN/Tax-ID fields are auto-detected and masked during every copy. You can add or override masking on any other field.
Deterministic masking maps the same input to the same output every time, so a masked email or ID stays consistent everywhere it appears — relationships and joins across objects keep working.
Yes. Masking is configured per field, so you choose exactly what gets masked and how.
It covers the same need — keeping PII out of sandboxes — but masks during the copy rather than after a refresh, deterministically, into any org you already control.
In transit, as Syntharil replicates records from the source org to the target. The target org receives masked values.
Yes. Because masking is deterministic, foreign keys and cross-object references that share a value stay consistent after masking.