DataMasker: Every Question Answered

DataMasker installs directly from the Salesforce AppExchange: search for 'Cloud Compliance DataMasker'. Installation takes under 5 minutes. No code required. After installation, configure your first masking profile by selecting objects, fields, and substitution types through a point-and-click table interface. Most teams complete their first sandbox masking run within the same day as installation.

No. DataMasker is fully configured through Salesforce screens: no Apex, no Flow, no custom code required for standard implementations. You select objects and fields, choose substitution types (realistic name, email, phone, etc.), and save the profile. Advanced use cases like REST API triggering from CI/CD pipelines require a connected app setup but no custom Apex.

DataMasker works with Enterprise, Unlimited, and Performance editions. It supports all sandbox types: Developer, Developer Pro, Partial Copy, and Full Copy. It also works with scratch orgs for DX-based development workflows.

Most teams complete initial deployment: AppExchange install, masking profile configuration, and first sandbox masking run: within one business day. Full production deployment with CI/CD integration typically takes 1-2 weeks. Cloud Compliance's implementation timeline is 3 weeks for all three products combined.

Yes. DataMasker has passed Salesforce's AppExchange Security Review: a rigorous independent assessment covering OWASP Top 10, data handling, encryption, and access controls. Review documentation is available for your security team on request.

DataMasker is designed for non-production environments: sandboxes and scratch orgs. It does not modify production data. This is intentional: the purpose is to ensure non-production environments contain realistic but fake data, eliminating PII exposure in developer and QA environments.

DataMasker supports multiple named masking profiles. Create a 'Developer' profile with aggressive masking (all PII fields), a 'QA' profile with selective masking (preserve some data patterns for testing), and a 'Demo' profile with specific substitutions for sales demo environments. Apply the appropriate profile when triggering each sandbox refresh.

DataMasker requires System Administrator profile or a custom profile with the DataMasker permission set assigned. The running user must have access to all objects being masked. For automated triggering via REST API, a connected app with appropriate OAuth scopes is required. No special Salesforce license add-ons are needed.

DataMasker supports: realistic name generation (first/last names by locale), email address substitution (preserving domain structure), phone number masking (by country format), address masking (realistic but fake addresses), date offset (preserving relative timing while shifting absolute dates), numeric range masking (preserving statistical distributions), picklist value substitution, free-text replacement, and custom pattern masking using regex. All substitutions are format-preserving: masked data looks like real data.

Formula fields cannot be directly masked because they are calculated, not stored values. DataMasker masks the source fields that feed the formula: so the formula result changes automatically. For example, masking FirstName and LastName causes a Full_Name__c formula field to show the masked values. If you need the formula field output masked independently, contact Cloud Compliance: there are configuration options for specific scenarios.

Yes. DataMasker can mask picklist fields by substituting values with other valid picklist options from the same field. You configure substitution mappings: e.g., 'Healthcare' → 'Technology', 'Enterprise' → 'SMB'. This preserves the picklist's data integrity constraints while obscuring the real value.

DataMasker's grouping and sequencing feature maintains referential integrity. You define groups of related objects (e.g., Contact + related Cases + related Opportunities) and DataMasker processes them in sequence: ensuring that Contact.Name changes propagate consistently to all related records that reference the same contact. Without grouping, related records could end up with inconsistent data.

Yes. DataMasker supports filter conditions on masking rules. Apply masking only to records matching specific criteria: e.g., mask only Contacts where RecordType = 'Customer', or only Opportunities where CloseDate > 2020-01-01. This is useful for partial copy sandboxes where you want to preserve some reference data while masking customer PII.

DataMasker works alongside Shield Platform Encryption. Shield encrypts field values at rest: only authorized users see decrypted values. DataMasker masks the decrypted values with realistic substitutes. The two products work together: Shield provides production-level encryption, DataMasker provides non-production PII elimination. They address different problems and are fully compatible.

Yes. DataMasker can mask the local part of an email address (before @) while preserving the domain. For example, john.smith@enterprise.com becomes a.johnson@enterprise.com. This is useful when email domain is used as a proxy for customer company: preserving domain structure maintains test data coherence.

Person Accounts are fully supported. DataMasker treats Person Account records as a unified Contact+Account object and applies masking rules to both the Account Name (which mirrors the person's name) and the associated Contact fields simultaneously. The grouping feature ensures Account and Contact fields are masked consistently.

Yes. DataMasker supports Experience Cloud objects including portal user records, community member data, and associated CRM objects. Configure masking rules for the relevant objects: DataMasker processes them the same as standard Salesforce objects. This is important because Experience Cloud sandboxes often contain both internal and external user PII.

Yes. DataMasker works with all custom objects and custom fields. In the masking profile configuration, all objects in your org: standard and custom: are available for selection. Custom objects with lookup or master-detail relationships to standard objects can be included in grouping/sequencing configurations.

DataMasker processes approximately 5 million records per hour under standard conditions. For large orgs, this scales to 99 million records in 24 hours using parallel batch processing. Processing speed depends on org configuration, batch size settings, and the number of fields being masked per record.

DataMasker uses Apex Batch processing with configurable batch sizes (default 200 records, tunable up to 2,000). Each batch respects CPU timeout limits and heap size constraints. For very large volumes, DataMasker spawns parallel batch jobs against different record subsets: governor limits are never hit because no single transaction processes the full volume.

For orgs with complex object schemas or many fields per record, start with 200 records/batch. For simpler schemas with few masked fields, 500-1,000 records/batch is safe. Avoid maximum batch sizes when masking objects with many relationships: the grouping/sequencing overhead increases per-record processing time. Cloud Compliance's implementation team can advise on optimal settings for your org.

Yes. DataMasker can run simultaneous masking jobs against different objects. This is how 99M records in 24 hours is achieved: parallel batch jobs process Contact, Account, Opportunity, and custom object records simultaneously. Configure parallelism in the job settings, subject to your org's concurrent Apex batch job limits (typically 5 concurrent batch jobs).

For a typical enterprise org (1-5M records), a full masking run takes 2-4 hours. For large orgs (10-50M records), 8-12 hours is typical with standard parallelism. Resolution Life masked 125M records in 48 hours: this required maximum parallelism configuration. Actual time depends on record count, fields per record, and org performance during the masking window.

DataMasker uses Apex Batch, which runs asynchronously in Salesforce's background job queue. During masking, the sandbox remains accessible: users can continue working. For very large jobs, some users may notice slower query performance as the batch jobs consume processing resources. Schedule masking runs during off-hours for large orgs to minimise impact.

DataMasker logs all masking operations. If a batch job fails, completed batches are preserved: only the failed batch needs to re-run. DataMasker includes a job resume feature: re-run from the point of failure rather than starting over. All errors are logged with the specific record ID and field that caused the failure, enabling targeted debugging.

Yes: this was developed specifically for FSC deployments. DataMasker's grouping and sequencing feature resolves FSC row-locking by processing related FSC records (Person Accounts, Financial Accounts, Financial Holdings) in a dependency-aware sequence that prevents concurrent lock contention. Resolution Life (125M records, full FSC deployment) is a production example.

DataMasker exposes a REST API endpoint. In Copado, add a post-deployment step that calls the DataMasker API with your masking job configuration as JSON. The API returns a job ID; Copado polls for completion before marking the pipeline stage complete. Full Copado integration documentation available from Cloud Compliance.

Yes. Use Gearset's post-deployment webhook feature to call the DataMasker REST API after a sandbox deployment. Pass the sandbox name and masking profile as parameters. Gearset marks the deployment complete after DataMasker confirms the masking job has finished.

Yes. DataMasker's REST API can be called from any CI/CD platform that supports HTTP requests. Use a `curl` command or your preferred HTTP client to POST the masking job configuration to the DataMasker endpoint. Add the API call as a pipeline step after sandbox refresh and before developer access is granted.

A typical DataMasker API call specifies the target sandbox, masking profile name, and optional overrides. The response includes a job ID for status polling. Authentication uses a Salesforce connected app (OAuth 2.0). Cloud Compliance provides sample payloads and Postman collections for common integration scenarios.

Yes: two methods: (1) REST API trigger from your CI/CD pipeline immediately after refresh, or (2) Scheduled Apex within Salesforce to run at a configured time after refresh. The API method is recommended for teams with active DevOps pipelines. The scheduled method works for teams with periodic (not continuous) refresh cycles.

Yes. DataMasker can mask scratch orgs via REST API after org creation and data loading. In a DX workflow: create scratch org → load seed data → call DataMasker API → grant developer access. The masking profile is the same as for sandbox environments.

DataMasker's REST API returns a job status endpoint. Poll until status = 'Completed' or 'Failed'. On completion, the response includes a summary: objects processed, records masked, fields masked, and any errors. Log this summary as a pipeline artifact. For additional validation, DataMasker creates a masking audit log record in Salesforce that your pipeline can query.

Yes. DataMasker profiles are stored as Salesforce records: multiple users with appropriate permissions can create and edit profiles simultaneously. Profile changes are subject to standard Salesforce record-level access controls. Version control for masking profiles can be achieved by exporting profile configurations as metadata.

Cloud Compliance provides: implementation documentation, API reference, sample integrations for Copado/Gearset/GitLab CI, and Customer Success Manager support. Enterprise customers receive dedicated implementation support for CI/CD pipeline integration. Contact support at cloudcompliance.app for integration assistance.