Dynamics 365 Business Central: cleaning sensitive configurations when copying production to sandbox

When working with Dynamics 365 Business Central on real projects, I think that it’s quite common to have the need to create a Sandbox environment as a copy from a Production environment. This is useful for testing purposes but also for some troubleshooting.

You already know that you can create a new Sandbox environment as a copy of a Production environment directly from the Admin Center:

When you create a sandbox environment as a copy of another environment, the new environment is created on the same application version as the environment that you are copying. The new environment will contain all per-tenant extensions and AppSource extensions that are installed and published in the original environment that is being copied.

When you perform this action, you should also be aware of possible impacts related to configurations. A Production environment can interact with external systems and this could be dangerous if not handled carefully.

When a sandbox is created as a copy of a production environment, Microsoft does the following for you automatically:

• The job queue is stopped
• Any base application integration settings are cleared
• Outbound HTTP calls from extensions are blocked by default and must be approved for each extension, otherwise instead of an external call, the system will display an error message like “The request was blocked by the runtime to prevent accidental use of production services“.

But what happens if someone accidentally ignore this last error message for example?

Imagine to have an extension that reads orders from an external system like an eShop or that sends shipments to a WMS or electronic invoices to the regulation’s authority. This could potentially create a serious problem.

How can you react on a copy of a production environment to a sandbox one and then act accordingly in an automatic way (transparent for the end user) in order to avoid this potential problem?

The Microsoft System module offers a codeunit called Sandbox Cleanup that raises some events when copying a company to a sandbox environment. It exposes the following events:

• OnClearConfiguration: subscribe to this event to clean up data when copying a company to a sandbox environment.
• OnClearCompanyConfiguration: subscribe to this event to clean up company-specific data when copying to a sandbox environment.
• OnClearDatabaseConfiguration; subscribe to this event to clean up environment-specific data when copying to a sandbox environment.

If you want to automatically reset your configurations for external integrations, you can handle the cleanup login into the following event subscriber:

Here you can for example reset the external endpoint url and so avoiding that your demo shipments created from the new sandbox are automatically sent to the external WMS for delivery without knowing it 😀

The Sandbox Cleanup codeunit relies on the Environment Triggers codeunit, that exposes the following two events that can also be used for this task:

• OnAfterCopyEnvironmentToSandbox
• OnAfterCopyEnvironmentToSandboxPerCompany

Remember that the “copy to sandbox” action can be performed by the partner but also by the customer’s admin, so act accordingly when needed if you want to be safe 🙂