Picture this scenario: It's Tuesday morning. Jim, a UAT tester, logs into the Microsoft Dynamics CRM testing environment to make sure that his Contacts have migrated properly from the legacy CRM system. Jim navigates over to his "My Contacts" view and sees his Contacts in the system. Seeing that they are there, he decides to execute the next test script, which is adding some Contacts to a Marketing List for a PowerMailChimp campaign. Jim adds 507 of his Contacts to the "Test Campaign Please Ignore" Marketing List, not thinking anything of it. The test scripts pass with flying colors, and Jim is happy.

Later that day, Larry (another UAT tester) is tasked with ensuring that PowerMailChimp is up and running and is accessible to the marketing team. Larry logs in and performs the test script for PowerMailChimp, synchronizing users and ensuring the Campaign setup works. Larry accidentally forgets the step to check and ensure that only fake Contacts are on the associated Marketing List.

That night, Rich (a third UAT tester) executes a PowerMailChimp test sent against the "Test Campaign Please Ignore" campaign, under the assumption that only test users are on it. The following email is sent out:

Subject: Test Campaign Please Ignore

"Dear ,

This is a test. This is only a test. Testing 123. Test. Woo Hoo! It Works!

Sincerely,

"

The next morning, Jane, the customer service manager, starts noticing a larger than usual volume of unsubscribe notifications arriving, and her team notices a heavier than normal call volume asking about some email that was sent. Under her breath, Jane mutters, "oh great."

Don't let this happen to you!

One drawback to using a CRM sandbox/development/testing/training environment is that sometimes an accidental email gets sent to one or more Contacts with real email addresses. In the scenario above, the CRM Administrators should have taken the following steps to prevent the email from going out:

1. Ensure that the CRM email router and/or Server Side Sync are disabled.

2. Configure "Process Emails Only for Approved Users" to be checked in System Settings.

3. Reject all user emails in the sandbox, development, test and training orgs.

In our example, the issue was that the emails were not scrubbed, so they were still available for use in Outlook Address Book Sync, Outlook Contact Sync, Mobile Devices, CRM form email hyperlinks, and Marketing Campaigns.

Ok, great. You've scared me. Now, what can I do?

Scrub your email addresses! In a test environment, best practice is to build functionality that will replace emails that are migrated/integrated with dummy email addresses. That way, in the event that the scenario above plays out, emails will not be sent to customer-facing email addresses.

This can be accomplished in a number of ways. Here are a few suggestions of things to do in parallel:

1. Prevent data migrations and integrations from sending email addresses to the non-production environments. This can be done by removing the mapping from the fields or replacing everything after the "@" sign with some arbitrary domain (like contoso.com).

2. Use CRM Business Rules on the email address forms to clear out or modify email addresses (as mentioned above) if they are modified in CRM by an end user.

3. Write a simple ETL (SSIS/Scribe/BizTalk/etc.) package that runs periodically throughout the day to remove or modify email addresses from non-production environments.

Here's an example of parsing an email and then concatenating @contoso.com to email if email is not already scrubbed:

One question: How will I test data accuracy if I remove or modify email addresses?

Excellent question! One suggestion is to enable Audit so you can see what the email address was without any custom development.

If that is not sufficient or you need to interact with the data, you can create a custom entity in CRM to store the email address. Instead of a business rule to perform this action, you can write a plugin to perform the above action on the email address fields:

1. Create an "Email Scrub Log" entity in CRM and build a relationship to the entities you wish to scrub.

2. Write a plugin which triggers a pre-image to grab a snapshot of what the email address was before it was modified.

3. Have the plugin check that the email is not already scrubbed (e.g. it doesn't already have @contoso.com in the email address).

4. Create a new "Email Scrub Log" record and associate it to the record you are scrubbing.

5. Store the email address on the new record.

Here's an example of an email scrub log entity in action:

Email Scrub Log associated with Rita Book:

Scrubbing emails in CRM doesn't have to be a massive project, nor does it have to be time-consuming. The benefits far outweigh the time to build the solution, so don't get caught off guard with thousands of unsubscribe notifications because you accidentally sent a test email in a non-production environment. Haven't tried PowerMailChimp yet? Go ahead and try out the free 30-day trial today! You might feel like this after you try it for yourself!

Happy CRM'ing!