Copy a company without the test environment sending emails

You copy the company to test. Then job queues start running, and emails go out to real customers. This article distinguishes between copying a company and copying an environment, shows what Microsoft Learn says about job queues and email setup in each case, and gives a checklist so test data does not end up with real recipients. You also get a checklist that can be used after every copy.

Company or environment

On the Companies page you can copy a company. That is a copy within the same environment. You can also copy a whole environment in the administration center, for example to make a sandbox from production. The two have different safeguards.

Microsoft Learn warns that you should not use a company copy as a backup. For backup, you export the database as a bacpac file.

What an environment copy does

When copying an environment, Learn mentions several protections: tasks in the job queue are stopped automatically, agents are turned off, outgoing HTTP calls from extensions are blocked, and a number of integration setups are set to disabled. Email accounts of the types Microsoft 365 and Current User are deleted, and SMTP server details are removed. You can see the stopped tasks on the Scheduled Tasks page and choose for yourself which ones should run again.

What a company copy does

Here Learn is more brief. It says that the password for an SMTP account is not carried over, and that Dataverse and Sales integration are cleared: connection settings, integration records, synchronisation jobs and synchronisation errors.

We did not find a description of job queue entries being stopped in a company copy, or of how email setup and scenarios are handled beyond the SMTP password. Do not assume, therefore, that it happens. Check it yourself.

It is email and the job queue in particular that hurt if you forget them. Dataverse and Sales are better protected, because Learn describes that they are cleared.

Checklist after a copy

Give responsibility for the checklist to one person, so it gets used every time.

Open Job Queue Entries and put on hold everything that should not run. Notifications from workflows are sent through the job queue, so approval emails can reach real users.
Open email accounts and scenarios. Remove or replace accounts, so the test cannot send from a real mailbox.
Check document sending profiles and customers' email addresses. Replace them in the test data if there is a risk that someone will send documents.
Turn off scheduled batch posting in the test.
Check integrations and web services that may point to production systems.
Write down what you have done in a fixed procedure, so the next copy follows the same steps.

Why the job queue is the biggest risk

The job queue runs tasks in the background: batch posting, notifications, synchronisation and much more. If a copy inherits active job queue entries, they can start running without anyone having asked for it. Learn says that all notifications about workflow steps are sent through the job queue, so a copy with active approval workflows can send messages to real users.

That is why the first step after a copy is to look at the job queue entries before anyone starts testing.

Choosing the type of copy

If the purpose is testing with real data, an environment copy to a sandbox is often safer, because more things are turned off automatically. Remember that an environment copy also brings all companies along, and that personal data in the copy requires the same care as in production. Learn says you must handle actions under privacy legislation in the copy yourself.

The idea Safe Company Copy is on our list of possible apps. It corresponds to an idea about putting all job queues on hold when a company is copied, which has about 128 votes. It is an idea we are considering, and not something you can download or buy.

If you copy often, make a fixed procedure with a name, an owner and a checklist. A copy without an owner easily ends up as a forgotten test company with real data.