SfSkills Domains Docs GitHub

Home / security / sandbox-data-masking

sandbox-data-masking

Use this skill when configuring or reviewing Salesforce Data Mask to protect PII/PHI in partial or full copy sandboxes after a refresh. Trigger keywords: data mask, sandbox masking, PII in sandbox, GDPR sandbox, HIPAA. NOT for sandbox refresh mechanics (use devops/sandbox-refresh-and-templates) or production data anonymization — use admin/sandbox-strategy.

Open the skill folder on GitHub

Sandbox Data Masking

This skill activates when a team needs to configure Salesforce Data Mask to protect sensitive data (PII, PHI, or regulated information) in partial copy or full copy sandboxes, or when investigating why a masking job did not run correctly after a sandbox refresh.

Before Starting

Gather this context before working on anything in this domain:

ContextWhat to confirm
Sandbox typeData Mask requires a partial copy or full copy sandbox. Not available for Developer or Developer Pro sandboxes.
LicensingData Mask is a paid add-on. Confirm the org has the Data Mask permission set license assigned before attempting configuration.
Encrypted fieldsShield Platform Encryption-protected fields cannot be masked. Configuration silently skips them; the real value remains. Most common wrong assumption.
Big Objects and External ObjectsNot supported by Data Mask. Plan separately for any PII stored there.
Field type supportSupports Text, Email, Phone, TextArea, URL, and certain custom types. Formula fields, Roll-up Summaries, and encrypted fields are not maskable.

Core Concepts

What Salesforce Data Mask Is

Salesforce Data Mask is a managed package from Salesforce Labs (licensed as an add-on) that runs inside your org and transforms field values in sandbox environments after a refresh. It does not move data outside Salesforce — the masking jobs execute as Apex batch jobs against the sandbox org's data directly. Data Mask is available only in partial copy and full copy sandboxes.

Data Mask is configured through a declarative UI (the Data Mask app installed from AppExchange). You define masking policies at the object and field level, then run the policy manually or trigger it via the SandboxPostCopy interface so it fires automatically at the end of a sandbox refresh.

Masking Types

Data Mask provides four masking types per field. Not every type is supported on every field type — the Help topic carries a compatibility table.

  1. Replace with Random Characters — substitutes randomly generated characters. Fastest replacement option; the result is not realistic-looking.
  2. Replace from Library — substitutes a similarly mapped word drawn from a Salesforce-supplied library (names, addresses, company names). Produces realistic-looking values, so format-sensitive tests and email-shape validation still exercise their logic. Slowest of the four.
  3. Replace Using Pattern — substitutes a value assembled from a pattern you define, for fields that must keep a specific shape (an account number, a policy reference).
  4. Delete — blanks the field. Simplest and fastest option; use when the value is irrelevant to testing. Do not point it at a required field or a field covered by a non-blank validation rule — the job aborts mid-run.

Rough speed order, fastest to slowest: Delete → Random Characters → Pattern → Library.

There is no "Deterministic" and no "Pseudonymous" masking type. "Deterministic" is Shield Platform Encryption vocabulary and does not belong to Data Mask at all; the property it describes — the same input always yielding the same output — is precisely the property Data Mask avoids, because masking is deliberately irreversible ("When you mask sandbox data, you can't unmask it"). If you need a value to match across two objects after masking, Data Mask will not do it for you: mask both fields, then reconcile them with your own post-mask job (see Example 2).

Compliance Scope

Under GDPR, HIPAA, and CCPA, personal data copied to non-production environments must be protected equivalently to production, or anonymized. Data Mask satisfies the anonymization requirement when configured for all relevant fields. A masking policy that misses even one object containing personal data — such as a custom object storing payment reference numbers — means the sandbox is still in scope for compliance obligations. Always cross-reference masking coverage against the org's data inventory or Record Information Architecture.

Common Patterns

Pattern 1: Automated Post-Refresh Masking via SandboxPostCopy

When to use: Any org running a full copy or partial copy sandbox on a recurring refresh cadence where manual steps cause compliance gaps or human error.

How it works:

  1. Create an Apex class that implements SandboxPostCopy and calls the Data Mask API to kick off the saved masking configuration.
  2. Register the class in the sandbox definition or in the sandbox request through the SandboxPostCopy interface.
  3. When the sandbox refresh completes, Salesforce invokes the class automatically. Data Mask runs its batch jobs before the sandbox becomes accessible.

The Data Mask managed package exposes an invocable Apex interface. Your SandboxPostCopy class calls it by name using Type.forName to avoid a hard compile-time dependency:

global class MaskAfterRefresh implements SandboxPostCopy {
    global void runApexClass(SandboxContext ctx) {
        Type dataMaskType = Type.forName('DataMask', 'DataMaskFacade');
        if (dataMaskType != null) {
            Object facade = dataMaskType.newInstance();
            // invoke the run method via reflection or interface cast
            // actual method name: DataMaskFacade.runConfiguration(String configName)
        }
    }
}

Why not manual: Manual post-refresh masking relies on a human remembering to run the job. In practice, developers request sandbox access before masking is complete, exposing real data. Automation removes the window of exposure.

Pattern 2: Field Coverage Audit Before Enabling Sandbox Access

When to use: Before granting any developer or QA access to a newly refreshed full copy sandbox.

How it works:

  1. Export the Data Mask configuration as a CSV or screenshot for each object.
  2. Cross-reference against the org data dictionary or the fields marked as "Contains PII" in your custom metadata.
  3. Run a SOQL spot-check on a known PII field (e.g., SELECT Email FROM Contact LIMIT 1) and confirm the value does not match a known production email format (e.g., a real domain rather than @example.com).
  4. Lock the sandbox profile to a read-only permission set until the audit is complete.

Decision Guidance

SituationRecommended ApproachReason
Real customer emails must not appear in sandboxReplace from Library masking on Email fieldsPreserves valid email format for workflow testing without exposing real addresses
Cross-object value consistency needed after maskingMask both fields, then reconcile them with your own post-mask Apex/data job — Data Mask has no setting for thisMasking is irreversible by design and gives no same-input-same-output guarantee. Budget for the reconciliation step in the refresh runbook rather than expecting a masking type to deliver it
Field value is irrelevant to any test scenarioNull/Delete maskingSimplest, fastest; eliminates all residual data risk
Field is encrypted with Shield Platform EncryptionNo Data Mask option; plan alternativeData Mask cannot access encrypted field values; must use a separate anonymization strategy or deprovision encrypted data before copy
PII exists in a Big ObjectOut of scope for Data MaskBig Objects are not supported; document as compliance exception with manual remediation plan
Developer sandbox tier requestedUpgrade to partial copy or use seeded dataData Mask is unavailable; advise against copying production data to Developer sandbox at all

Step-by-step instructions for an AI agent or practitioner activating this skill:

  1. Gather context — confirm the org edition, relevant objects, and current configuration state
  2. Review official sources — check the references in this skill's well-architected.md before making changes
  3. Implement or advise — apply the patterns from Core Concepts and Common Patterns sections above
  4. Validate — run the skill's checker script and verify against the Review Checklist below
  5. Document — record any deviations from standard patterns and update the template if needed

Review Checklist

Run through these before marking sandbox access as compliant:

Salesforce-Specific Gotchas

  1. Encrypted fields are silently skipped — Data Mask does not throw an error when a Shield-encrypted field is included in the masking policy. It silently skips those fields and the real encrypted value remains in the sandbox. There is no warning in the job log. Verify by checking which fields have Shield encryption enabled in Setup > Platform Encryption, and remove them from the masking policy entirely; handle separately.
  2. Required fields configured for Null masking cause batch abort — If a field with a Required field-level setting is configured for Null/Delete masking, the batch job aborts mid-run with a DML error. Because Data Mask processes records in batches, some records may already be masked while others retain original values when the job aborts. Always verify required vs. optional field settings before configuring Null masking.
  3. Data Mask does not cascade to lookup-related objects automatically — If you mask Contact.Email but the same email address appears on a related custom object (e.g., Support_Request__c.Requester_Email__c), that field retains the real value unless explicitly included in the masking policy. The masking configuration is per-field; there is no automatic relationship traversal. Cross-reference against all objects that copy or mirror PII fields.

Output Artifacts

ArtifactDescription
Data Mask configuration planObject-by-object, field-by-field mapping of masking type, documenting any excluded fields and the reason
Post-refresh runbookStep-by-step instructions for running Data Mask after each sandbox refresh, including who runs it and access control gates
Compliance gap registerList of fields not maskable due to platform limitations (encrypted fields, Big Objects) with remediation or acceptance notes
SOQL spot-check queriesReady-to-run queries to verify masking effectiveness on key PII fields after a job completes

Package files