Refreshing a Dynamics 365 Sandbox - How to Minimise Risk

Sandbox refresh

Across your deployment of Dynamics 365 a need may arise to restore the sync between Production and Sandbox environments. This creates significant risk so in this post we've shared our best practices for carefully managing the refresh process, and how to make sure these stay in sync.

First, lets look at the two main types of Dynamics 365 environments:

Sandbox (or Non-Production) environment is the development and test area, where all the latest customisations should initially be deployed and can be tested before these are released into production.

Each Dynamics customer is able to deploy one, or more, non-production environment at no additional cost (subject to sufficient cloud storage capacity). In some scenarios it can be beneficial to deploy multiple Sandboxes that will separate development and user testing environments.

The Production environment is your live Dynamics system. No customisations or developments should be configured or deployed here until they have first been tested in Non-Production and confirmed to work successfully.

If there is a need to refresh a sandbox from the production environment this is often because customisations have been made directly onto the live system. As a result, the production and sandbox environments are no longer in sync and a refresh is needed to bring these back in line.

This is not a recommended outcome due to the risk it creates. That's because all changes and customisations contained within the sandbox will be lost when this is refreshed from the Production site.

Before making a refresh, we strongly recommend speaking to your systems administrator and support partner to check if there are any unpublished developments or customisations. This work won't be present in the Production site and so it will be lost when the Sandbox is wiped and replaced with a copy from the live site.

It's important to note that this process will also remove any backups from the Non-Production site.

As a result, this requires careful management. A hasty sandbox refresh without considering these factors is a frequent cause of unpublished changes to be lost.

To avoid this, always build in the Sandbox rather than Production. This will help protect unpublished changes and make sure these sites stay in sync.

In a scenario where the Sandbox is no longer in sync with the live site, before completing a refresh, any unpublished work that you want to retain must be pushed to Production to avoid this being lost when the refresh is applied.

This should be a one-off process. By ensuring each change is pushed from Sandbox to the Production site as a managed solution using the Power Platform admin centre, there shouldn't be a need to refresh your Sandbox again. This will also remove any need to manually recreate any solution which has been built in a non-production site.

Further suggestions to reduce risk when a Sandbox is refreshed include:

  • Disable Dynamics 365 mailboxes to prevent emails from being incorrectly sent from the Sandbox environment.
  • To avoid impacting documents in Dynamics 365 which are managed by SharePoint it may also be beneficial to deactivate the SharePoint integration or create a non-production environment in SharePoint.
  • If limited cloud storage capacity is available, consider running a bulk delete across system jobs, attachments, audit logs and other records to reduce storage consumption.

In addition to phone support and consultancy to help administrators complete a Sandbox refresh, Preact offers training for solution management. This topic is also covered in our eLearning Academy.

Please get in touch if you have any questions about the sandbox refresh process or how to best manage and deploy solutions across your Dynamics environments.