Salesforce Data Masking
Salesforce data masking replaces sensitive field values — names, emails, phone numbers, financial figures — with realistic but non-identifying substitutes before real records ever reach a sandbox. SyntraFlow is designed to mask consistently, preserving referential integrity so the data still behaves like production without being production.
This page focuses narrowly on masking real records. For the wider practice of preparing and provisioning test data, see the Salesforce test data management pillar.
Why raw production copies are the wrong default
A Full or Partial Copy sandbox can carry real customer records into an environment where more people have access and controls are looser than production. Every such copy multiplies the places a name, email, phone number or contract value can leak from, and it complicates data-minimisation and retention obligations. Masking removes the sensitive content while keeping the data useful, which is why a raw copy should rarely be the default.
Masking transforms sensitive fields in place: an email becomes a different but well-formed email, a salary becomes a plausible figure, a national ID becomes a format-valid placeholder. The record still exercises the same automation and screens, but no value identifies a real individual. The hard part is doing this without breaking the data — and that is where consistency and referential integrity matter.
Masking is easy to underestimate. Replacing a single field is trivial; masking a whole org so it stays coherent is not. The same customer name can appear on an Account, dozens of Contacts, hundreds of Cases and a pile of custom rows, and if each occurrence masks to a different value the relationships that joined them silently break. Amounts feed rollups and forecasts, so a careless number can push a record outside a validation rule. Free-text fields hide personal data in unpredictable places. Effective masking therefore has to be consistent, format-aware and applied across every object at once — not field by field in isolation — which is why it belongs in a managed data pipeline rather than a set of manual updates.
Masking applies to real records; when you instead want records that never touched production at all, generate synthetic test data, and when you want a smaller realistic slice, use data subsetting. Masking changes records, not configuration; the objects, fields and Flows themselves are metadata, a separate discipline.
How SyntraFlow is designed to mask Salesforce data
These capabilities are available for demonstration and proof-of-concept validation. The aim is masked data that is safe, still valid, and still relationally intact.
Sensitive-field discovery
Designed to help identify which fields hold personal, financial or commercial data across standard and custom objects, so nothing sensitive is masked by omission.
Consistent masking
Designed to map the same input to the same output everywhere it appears, so a customer name masks identically on the Account, its Contacts and its Cases and joins still resolve.
Format-preserving substitutes
Designed to keep masked values well-formed — valid email patterns, phone formats, checksum-shaped IDs — so field validation and downstream logic still accept them.
Referential-integrity preservation
Designed to keep foreign keys, external IDs and lookups aligned through masking so a masked slice behaves like a coherent piece of production, not a broken fragment.
Field-type-aware rules
Designed to choose a masking technique per field — substitution, shuffling, nulling or ranged randomisation — that fits the data type and how the field is used.
Irreversible transformation
Designed so masked values cannot be trivially reversed back to the original, keeping the real value out of the lower environment for good.
Custom-object coverage
Designed to mask sensitive fields on each org's own custom objects, not just the standard model, because sensitive data often lives in bespoke fields.
Role-based control
Designed to work with role-based access so who can define masking rules and run a masking job can be governed centrally rather than ad hoc.
Masking audit trail
Designed to record which fields were masked, by which rule and when, giving teams a traceable history of how sensitive data was handled.
Masking techniques by field type
Different sensitive fields call for different techniques. The table shows representative approaches — the right choice depends on how each field is used downstream.
| Field example | Technique | Why it fits |
|---|---|---|
| Contact name | Substitution | Replaces with a realistic but unrelated name; consistent across records. |
| Email address | Format-preserving substitution | Keeps a valid pattern so email fields and flows still accept it. |
| Phone number | Format-preserving randomisation | Retains length and shape without dialing a real line. |
| Opportunity amount | Ranged randomisation | Keeps values plausible for rollups while hiding real figures. |
| National / tax ID | Checksum-shaped placeholder | Passes format checks without being a real identifier. |
| Free-text notes | Nulling or redaction | Removes unpredictable embedded personal data that is hard to parse. |
Consistent masking across connected systems
A masked customer in Salesforce should mask the same way in the ERP or billing system an end-to-end test touches, or the join between systems breaks. SyntraFlow is designed to apply consistent masking across Salesforce and connected systems such as Oracle ERP, SAP, Workday and NetSuite, so a shared identifier still matches on every side after masking. Explore the counterpart discipline in the Oracle ERP testing tool.
What masking is designed to achieve
Sensitive data stays in production
Real names, emails and financial figures never reach sandboxes or CI orgs, shrinking where a leak can originate.
Relationships stay intact
Consistent, integrity-preserving masking keeps joins, external IDs and rollups working so the data still behaves like production.
Tests stay realistic
Masked records keep production's shape and volume, so tests exercise the same paths without the privacy risk.
Validation still passes
Format-preserving substitutes keep masked values acceptable to field validation and downstream logic.
Governed and traceable
Role-based control and an audit trail give teams a defensible record of how sensitive data was handled.
Smaller exposure surface
Fewer environments hold real data, simplifying data-minimisation and retention across the testing estate.
Data masking FAQs
What is Salesforce data masking?
It is replacing sensitive field values — names, emails, phone numbers, financial figures — with realistic but non-identifying substitutes before real records reach a lower environment, so tests run against production-shaped data without exposing any real individual.
Why not just copy production into a sandbox?
A raw copy spreads real customer, employee and commercial data into environments with broader access and weaker controls, multiplying where it can leak from and complicating data-minimisation and retention obligations. Masking removes the sensitive content while keeping the data useful for testing.
How does masking preserve referential integrity?
Consistent masking maps the same input to the same output everywhere it appears, so a masked customer name is identical on the Account, its Contacts and its Cases. Foreign keys and external IDs stay aligned, so joins and rollups still resolve after masking.
Will masked data still pass validation rules?
It is designed to. Format-preserving substitutes keep emails, phone numbers and IDs well-formed, and field-type-aware rules keep amounts and dates within plausible ranges, so validation rules and downstream automation still accept the masked values.
How is masking different from synthetic data?
Masking transforms real records so they keep production's exact shape and quirks while hiding sensitive values. Synthetic data is generated from scratch and never touches production. Choose masking for realism, synthetic generation for zero exposure or scenarios that do not exist yet.
Can masking cover custom objects and fields?
Yes. Sensitive data often lives in bespoke fields, so masking is designed to cover each org's own custom objects and fields alongside the standard model, with sensitive-field discovery to reduce the chance a sensitive value is missed.
Keep sensitive data out of your sandboxes
See how SyntraFlow is designed to mask Salesforce data consistently while preserving usability and referential integrity.