Dynamics 365 CRM sandbox versus production environments

If you’ve been using Dynamics 365 CRM for a while or been involved in more of the technical support and customization requests with your Partner, you may have seen references to sandbox and production environments. What exactly are they and when would one be used over the other?

To put it simply, sandboxes are for playing around and testing customizations and features. Production environments are where you do your actual work. Now let’s dig in a little deeper into how to work with sandboxes, and how to move your sandbox content into a production environment if/when you want to!

Customizing in a Sandbox

Dynamics 365 CRM is a very customizable and extensible system. On top of that, Microsoft is continually adding and updating features. It’s not the best idea to start messing around with unfamiliar features or system customizations when it could have direct impacts on your live business data. Luckily, we can create copies of our existing data and system configurations as a sandbox environment. It is housed within the same overall tenant but is sectioned off as its own little ecosystem away from our live data.

A sandbox environment includes the text “Sandbox” in the top ribbon.

A sandbox environment includes the text “Sandbox” in the top ribbon.

Partners like us at Syvantis (or in-house system customizers) will use sandboxes when testing new customizations and integrations. As is common with development work, a lot of stuff will break during the process of creating something new. So many pieces of CRM are linked to each other in some way, so as we make adjustments in one place, something else may stop working properly until we make adjustments there as well. If we develop in the production environment, we might cause interruptions to the work of our teams using the system.

These environments span across the entire Power Platform. This means we can use our sandbox environments with other apps like Power Automate to test workflows or Power Pages for portal development.

The production environment is where our sales, marketing, customer service, etc. teams will be working. Most will not ever need to worry about using a sandbox environment. However, if there are new features coming with one of Microsoft’s release waves available in public preview, a sandbox environment would be a great place to enable the previews. Sandboxes provides a chance to check out these new features and test how they fit into your processes.

Moving Changes from Sandbox to Production

Once it is time for the changes made in the sandbox to be merged into the production environment, there are a couple ways to do it. For smaller changes that aren’t really too complex, don’t take long to recreate, or don’t have much impact on the system, we can simply recreate manually it in production by referencing the sandbox version. However, for larger overhauls, or when we have a bunch of smaller details that affect many entities, we can use what are called solutions. Solutions allow us to group related customizations into one package to quickly export and download from the sandbox environment. Then that package can be imported into the production environment. Depending on the size of these solutions, the import can cause slowdowns for people using the system. For those instances, we try to run the import at the end of or after business hours.

Migrating changes from sandbox to production environments via Solutions.

Migrating changes from sandbox to production environments via Solutions.

Sometimes, really small customizations like simple new fields on a form might be made directly in the production environment. Over time it can lead to differences in the datasets between the sandbox and production environments that cause imported customizations to have new issues that were not seen while in the sandbox. By packaging the changes into solutions, they can be easily reverted until that issue is fixed. In those circumstances, we may do something like recopy the production environment down to our sandbox, then import the solution to resolve whatever problem existed.

The list of environments you can access is available via the Power Platform Admin Center. Each environment has its own set of permissions and security role assignments. Your may not currently have security access to the sandbox(es) in your tenant, and if that’s the case, your system administrator or Microsoft Partner can help with access. As a note, you will also see an environment that is set to “Default” type. That environment is largely only used in initial configuration and setup. No real work or testing should be done there.

The third environment is the “Default” Type. That environment is largely only used in initial configuration and setup. No real work or testing should be done there.

The third environment is the “Default” Type. That environment is largely only used in initial configuration and setup. No real work or testing should be done there.

We use production environments for all of our live work and data. It’s what users will be in for all their day-to-day work. We have sandboxes as support environments to test new features and customizations without hurting our real data. We can then transfer customizations from sandboxes to production environments via solutions. Be sure to get in touch with your system administrator or us as your Microsoft Partner if you’d like to set up and use a sandbox in your CRM!

Previous
Previous

Managing contact consent in Dynamics 365 Real-time Marketing

Next
Next

How to create Power BI reports people really care about