Data masking lets us conceal sensitive information such as names and emails during a data deployment to a sandbox. The complexity of the production data still exists, but developers can't access real customer information.
Configuring which fields to mask
Salesforce data masking is part of Gearset's data loader, so to get started we kick off a data deployment as usual by selecting the objects we want to deploy. In this example, we'll deploy some Contact records and their related Account records.
When we click
NEXT, we'll go to the data masking page. This shows the objects in the deployment with the fields that Gearset can mask. We also see a sample of the masked output for each field.
Masking can be turned on or off for individual fields or entire field types. The toggles on the left let us turn masking on or off for all fields of a particular type. The list on the right configures masking for individual objects or fields.
Once we're happy with the masking selections, we can go ahead with the deployment. In this example, we'll mask the FirstName, LastName and Email on the Contact object.
We can see that the Contact in the source and the Contact in the target have different values for FirstName, LastName and Email. The Contact is still attached to the correct Account.
There are a few important caveats to data masking:
It's crucial to remember there's no rollback available for data deployment, so make sure you've taken a backup of any important data in the target org before you deploy.
Gearset won't let you mask data if the target is a production org, to help avoid costly deployment mistakes.
If an object is being upserted, then you can't mask the external id field, because the upsert uses the value of that external id field to match records.
If a masked field is empty on a record in the source, then the field will remain empty on the record in the target.