When I migrate data I often add .invalid to all the email fields in the org. More than once this saved my team from accidentally sending a large number of messages. Having a tool to do this easily in a sandbox has been on my todo list for a long time.

Why Invalidate Salesforce Emails

Salesforce automatically adds .invalid onto the end of email addresses of Users to avoid accidental sends from sandboxes. This is great when you have an experience cloud portal setup. Because Salesforce’s core platform is not an email marketing platform Contacts, Leads, and other objects with email fields are left unaltered. But lots of organizations use the core platform to drive a marketing platform. The use add-ons and data syncs, or they use the org to send transactional email directly from Salesforce. When the org is the tool that initiates the send, there is a risk that a sandbox with real data can send invalid messages. I’ve seen sandboxes send a lot of messages during testing of new features or when an automation was left switched on that should have been disabled.

Most Salesforce consultants I know have stories about times when an org sent unwanted email messages to a client’s contacts. Those events are embarrassing at best. At worst they can expose you to financial or legal liability.

Often these events happen when someone makes a simple error with a full copy sandbox, or an org with migrated data under review. The story outline generally is that while testing an automation, or a scheduled process, a team member sets Salesforce to send messages. They forget to disable email again, or they don’t think about a scheduled automation set to run at 2 AM. Minutes or hours later that sandbox triggers dozens, hundreds, even thousands of emails.

Can’t I Just Disable Email in Salesforce?

You can, and should, disable email deliverability in most sandboxes most of the time. But in my experience that’s not sufficient all of the time.

That setting is good, but less than perfect. Sometimes you need deliverability switched on to test features or deploy changes. Sometimes you use a 3rd party email system that ignores that setting. By actually breaking every email address nothing can slip through.

How My Salesforce Email Invalidator Works

This tool uses a series of custom metadata records to determine which objects and fields have emails you want to invalidate (it comes with a sample record to invalidate the Email field on Contact). When the batch process runs – either from the provided app or post sandbox copy – it will add .invalid onto the end of any existing data in the field. It does not check to see if the value is actually an email, but it does ensure .invalid is only added once and ignores blank values.

The tool provides an app that gives you a place to see and update the exiting field list, a button to initiate the process, and allows you to replace the .invalid text with a different string. You can also have it automatically run after a sandbox completes its process by entering InvalidateEmailSandboxPostCopy as the Apex class to run when creating the sandbox. I created the tool to be metadata driven so that the setup carries down from the production org into new sandboxes.

Security

Please be careful when installing and using my email invalidator. It is designed to break data – that’s the whole point. I have not put it through Salesforce security review, and I don’t plan to bother. I’m not even sure they would approve a tool designed to break data. It does have a permission set that should be giving out on a very restricted basis to highly trusted users – ideally don’t assign it to anyone in production including yourself.

I am releasing the invalidator tool as an open source project. You are free to review the code and validate that it does what I’ve described. I will do my best to answer any questions you post to the issue queue.

Installation

The current setup is just a collection of loose metadata in a repo. Until I get around to packaging it you’ll want someone who is comfortable with git and sf cli to support installation. You should clone the repo to your local machine and push all the metadata into your org with sf cli’s sf project deploy start command.

Of course please install in a sandbox first and test it out there before putting a copy in production. To make it easy to use over time it will need to be in production.

Feedback and Suggestions

I am open to, and interested in, feedback. Currently the tool is a very early alpha quality version. It works, but hasn’t been tested in a lot of use cases. In the project issue queue you can offer feedback, report bugs, or make suggestions. I’d also enjoy getting code contributions as well.