Privacy and preparation
Salesforce data masking for preparing CRM exports
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Salesforce data masking replaces personal values in structured fields, such as contact names, emails and phone numbers, inside a sandbox copy of your org. It does not clean free text in case comments, email bodies, task notes or attached files. Use masking for fields, a separate text redaction pass for narrative, and keep record relationships intact.
Key takeaways
- Field masking works on structured fields; narrative fields and files need a separate text and document pass.
- Masking belongs on a copy, such as a sandbox, never on the production org your teams use.
- Shield Platform Encryption protects data at rest; it does not de-identify an export made by an authorized user.
- Consistent replacement values keep accounts, cases and opportunities linked, which is where most of the value sits.
- Business context such as product names, stage names and close reasons should usually stay unmasked.
What does Salesforce data masking actually change?#
Salesforce data masking changes the values of selected fields in a copy of your org, replacing real names, emails, phone numbers and addresses with random, patterned or fictional values. Salesforce's own product for this, Data Mask, is positioned for sandboxes, so developers and testers can work with realistic records. Check current Salesforce documentation for supported objects, field types and licensing.
Masking works field by field. You choose an object, a field and a rule, and every record in the copy gets the new value. That approach is effective for structured identifiers and weak for anything a person typed in their own words.
For licensing, masking is a helpful first stage rather than the whole job. The CRM records buyers tend to value are the narrative ones: case threads, call notes and the emails that explain why a deal closed or a customer churned.
Data Mask, Shield and a plain export compared#
Data Mask, Shield and the standard export tools are often confused because all three touch sensitive fields. They solve different problems, and only some change the values that leave your org.
Product names, editions and features change over time, so confirm current capabilities with Salesforce documentation and your account team before designing a flow around a specific tool.
| Tool | Main purpose | Effect on a licensing export |
|---|---|---|
| Data Mask | Replaces field values in a sandbox copy | Structured fields arrive masked; free text and files are unchanged unless handled separately |
| Shield Platform Encryption | Encrypts data at rest in production | An authorized user's export generally contains readable values, so it does not de-identify |
| Data export service, Data Loader, Bulk API | Move records out of the org | Values arrive exactly as stored in the org you export from |
| Text redaction pipeline outside Salesforce | Finds and replaces personal details in narrative text | Cleans comments, email bodies and notes that field masking does not reach |
Which objects hold personal data that field masking misses?#
Personal data that field masking misses sits mostly in long text fields, activity records and files. The table maps common standard objects to where identifiers appear; custom objects deserve the same review.
Email signatures are the most common miss. A masked contact record can sit right next to an email body that still carries the person's full name, direct line and mobile number in the footer.
Installed managed packages add objects of their own. Call recording, e-signature and marketing automation apps often store transcripts, signed documents or engagement history in custom objects that a masking template built for standard objects never touches, so list every installed package during scoping.
| Object | Structured fields to mask | Free text and files to redact |
|---|---|---|
| Contact and Lead | Name, email, phone, mailing address, title | Description and custom notes fields |
| Account | Billing and shipping addresses; person account fields if enabled | Description and internal notes about key contacts |
| Case | Supplied name, email and phone; contact lookup | Subject, description and case comments |
| EmailMessage | From, to and cc addresses | Body text, signatures, quoted replies and attachments |
| Task and Event | Name and related-to lookups | Call notes and descriptions written by reps |
| Opportunity | Contact roles | Next step and description fields |
| Chatter posts and Files | Author and mention lookups | Post text, comments, uploaded documents and images |
A masked-sandbox export flow for licensing#
A masked-sandbox export flow keeps production untouched and puts every transformation on a copy you control. The order below is what makes the result reviewable.
Masking is destructive by design. Run it only in a sandbox or other isolated copy, confirm the target org before every job, and limit who can launch masking runs.
Plan the export route around the sandbox. A Salesforce partner's documentation notes that the Data Export Service is not available in sandbox environments, so a masked copy usually leaves through Data Loader or the Bulk API. Where the Data Export Service is used, its options to include attachments, Salesforce Files and CRM Content add processing time, and large exports arrive split across several zip files of CSVs, which matters when you decide how files will be handled.
Treat the exported files as raw personal data until the redaction pass is complete. Keep them in a restricted storage location with access logging, delete intermediate copies once the prepared version is approved, and note both steps in the log.
- Scope with metadata first: objects, record types, years of history and approximate volumes, agreed before any copy is made.
- Create a sandbox copy holding the objects and history in scope; available sandbox types and storage depend on your edition.
- Apply masking rules to structured identifiers, using consistent replacement for fields that join records.
- Export the masked objects with Data Loader or the Bulk API, keeping record IDs so relationships survive.
- Run a text redaction pass over descriptions, comments, email bodies and notes outside Salesforce.
- Decide on files separately: exclude them, or extract their text and redact it with the same pipeline.
- Review a sample of every object by hand, fix the rules, rerun, and record the results in the redaction log.
Why keeping relationships matters more than masking every field#
Keeping relationships intact matters because the value of CRM records lies in the sequence: a lead becomes an opportunity, the opportunity closes, the account opens cases, and the cases explain renewal or churn. Random replacement that gives the same account a different name on every record breaks that thread.
Use deterministic replacement for fields that link records, so the same input always becomes the same output inside the dataset. Google's Sensitive Data Protection API, for example, supports deterministic encryption and recommends it over format-preserving encryption where the original format need not be kept. Keep any key or mapping under the supplier's control, or destroy it once quality checks pass.
Leave business context unmasked unless it identifies a person: product and edition names, opportunity stages, loss reasons, case categories, priorities and resolution codes. Over-masking these fields strips out what a buyer would study.
Illustrative: an inspection software company prepares Sales Cloud and Service Cloud#
Illustrative: a fictional company sells inspection software to property management firms and runs Sales Cloud and Service Cloud. Its CTO wants to know whether several years of cases and opportunity notes could be licensed without exposing tenants or customer staff.
The team masks Contact, Lead and Case contact fields in a full copy sandbox and exports with the Bulk API. The first sample review finds tenant names inside case descriptions and phone numbers in email signatures, so the team adds a text redaction pass and a signature-stripping rule. Attached inspection photos are excluded because they show building interiors and tenants' belongings.
The resulting package keeps account and case relationships through consistent tokens, carries an exclusion list for files and Chatter, and goes to the general counsel with the redaction log for approval.
How SourceX approaches CRM preparation#
SourceX handles CRM exports in the Preparation step of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Before any preparation, the Rights step checks customer contracts and privacy notices that may limit how CRM records can be used.
Masking rules, the text redaction method, exclusions and sample review results are recorded as the privacy record in the SourceX Evidence Packet. The initial assessment uses only metadata such as objects, years and volumes, and the supplier approves the prepared export before delivery.
Frequently asked questions
Do we need Data Mask to prepare a Salesforce export?
No. Any method that reliably replaces identifiers and is well documented can work, including masking in a sandbox or transforming exported files in a controlled environment. What matters is that the rules are consistent, checked on samples and recorded in the redaction log.
Does masked CRM data count as de-identified under privacy laws?
Not necessarily. Masked fields can still sit beside text, dates and job titles that identify someone, and consistent tokens keep records linkable. Whether a prepared dataset meets a legal de-identification standard is assessed deal by deal with counsel, based on what remains.
What about person accounts and individual customers?
Person accounts combine account and contact fields for individual customers, so each record carries more personal data. Many B2B companies leave them out of scope, or mask both the account and contact field sets and review samples closely.
Should field history be included in the export?
Field history shows how deals and cases changed, which is useful context, but old values may hold the identifiers you masked in current fields. Mask or exclude history values for the same personal fields, and check how far back your org retains them.
Can we mask in production to save sandbox storage?
That is a poor trade. Masking overwrites values, so running it in production would destroy the records your teams rely on. Use a sandbox or another isolated copy, and plan storage around the objects and years actually in scope.
Sources
- Google's Sensitive Data Protection API supports deterministic encryption (CryptoDeterministicConfig) and recommends it over format-preserving encryption where the input alphabet need not be preserved. Source
- Sage People's guide to the Salesforce Data Export screen says the data export feature is not available in sandbox environments. Source
- Salesforce's Data Export Service has options to include images, documents, attachments, Salesforce Files and CRM Content; adding them increases processing time, and large exports arrive split into multiple zip files of CSVs. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.