Sandbox Best Practices: Masking Email Alerts

Sandbox Best Practices: Masking Email Alerts

Realistic testing scenarios require realistic data. However, using real email addresses in a sandbox can lead to unintended consequences, such as automated emails and notifications reaching actual customers and colleagues. Masking those addresses allows for authentic testing without the risk of impacting live systems or people.

When a sandbox is refreshed, Salesforce masks the email address on every User record by adding ".invalid" to the end of it. Email alerts are a different story. An email alert can include up to five additional email addresses, which lets it send to distribution lists or people who aren't Salesforce Users. Those additional addresses are copied into the sandbox exactly as they appear in production.

After a refresh, the sandbox's email deliverability is set to "System email only" (Setup > Deliverability > Access level). As soon as someone switches it to "All email" for testing, those unmasked addresses start receiving emails from the sandbox. That's why they should be masked before email delivery is turned on.

This still matters even though Salesforce ended support for Workflow Rules at the end of 2025. Email alerts are stored as part of each object's Workflow metadata, and they're widely used by Flows and approval processes.

You can edit the addresses one at a time in Setup, but I'll show you how to update all of them using the Salesforce command line interface (CLI). Run the commands below from inside a Salesforce DX project folder.

Steps for Masking Email Alert Addresses

1. Retrieve the Workflow metadata from the sandbox.

   sf project retrieve start -o interactiveties.sbx -m Workflow

   The CLI saves one file per object in your project's workflows folder. For example, force-app/main/default/workflows/Case.workflow-meta.xml.

2. Mask each additional email address. Open each file and look for <ccEmails> tags. Add ".invalid" to the end of every address between those tags. For example, this line:

   <ccEmails>support@interactiveties.com</ccEmails>

   becomes:

   <ccEmails>support@interactiveties.com.invalid</ccEmails>

   If you'd rather not edit the files by hand, this PowerShell command updates every file in the folder. It skips any address that already ends in ".invalid", so it's safe to run more than once.

   Get-ChildItem force-app/main/default/workflows -Filter *.workflow-meta.xml | ForEach-Object {
       $xml = [IO.File]::ReadAllText($_.FullName)
       $xml = $xml -replace '<ccEmails>(?![^<]*\.invalid<)([^<]+)</ccEmails>', '<ccEmails>$1.invalid</ccEmails>'
       [IO.File]::WriteAllText($_.FullName, $xml)
   }

3. Trim each file down to the alerts you changed. Keep the outer <Workflow> tag and the <alerts> entries that contain a <ccEmails> tag. Delete everything else, including <rules>, <fieldUpdates>, <tasks>, <outboundMessages> and any alerts without a <ccEmails> tag. Then delete any file that had no <ccEmails> tags at all. A trimmed file looks like this:

   <?xml version="1.0" encoding="UTF-8"?>
   <Workflow xmlns="http://soap.sforce.com/2006/04/metadata">
       <alerts>
           <fullName>Case_Escalation_Notice</fullName>
           <ccEmails>support@interactiveties.com.invalid</ccEmails>
           <description>Case Escalation Notice</description>
           <protected>false</protected>
           <recipients>
               <type>owner</type>
           </recipients>
           <senderType>CurrentUser</senderType>
           <template>Support/Case_Escalation</template>
       </alerts>
   </Workflow>

   Trimming is safe. A deployment only updates the components that are in the file. It doesn't delete the rules, field updates or alerts you removed. Keeping the files small also means you only deploy what you meant to change.

4. Deploy the updated files to the sandbox.

   sf project deploy start -o interactiveties.sbx -d force-app/main/default/workflows

   If your project keeps its metadata somewhere other than force-app, change the path to match.

5. Check the results. In the sandbox, open a few email alerts (Setup > Process Automation > Workflow Actions > Email Alerts) and confirm that the additional emails now end in ".invalid". Once they do, it's safe to set email deliverability to "All email".

Also worth checking: email alerts aren't the only place a real address can hide in a sandbox. Send email actions in Flows, Apex code that sends email, and the email fields on records such as Contacts and Leads (in Full and Partial Copy sandboxes) can all reach real people once email delivery is turned on.