When and How to Use Managed Versus Unmanaged Solutions in Microsoft Dynamics

It can be challenging to determine when to use managed and unmanaged solutions in Microsoft Dynamics. In this blog, we break down the differences and explain when and how to use each.

Dynamics 365 CE system administrators, developers and customizers constantly debate about managed versus unmanaged solutions best practices in Microsoft Dynamics 365 Customer Engagement environments, and it isn’t stopping anytime soon.

You use unmanaged and managed solutions to package and distribute customizations between environments. Solutions allow concentrated changes to the system without disrupting the application as a whole. When you need to update or change your D365 CE environment, you package that update into a solution in the development environment. Then you promote it to another environment as either a managed or unmanaged solution.

However, Microsoft intends that users use each type of solution for certain situations as they behave and interact within environments differently. It is important to understand the differences when using solutions to effectively customize your system and pick the best strategy for implementation.

In this blog, we want to clearly define managed and unmanaged solutions and how they interact between environments. We will also break down the situations when you use each. Let’s start by looking at the definitions.

Solutions: Unmanaged and Managed

First, let’s look at what solutions are in general. Solutions enable developers to package and maintain their customizations for Microsoft Dynamics 365 Customer Engagement. Customizers and developers distribute solutions so organizations can use D365 CE to install and uninstall the custom business functionals determined by the solution’s content.

To put it another way, compare a solution to a folder holding within it built-out objects that we can distribute. For example, let’s say we have our development, testing and production environments stood up. We have a request for an additional field, “Customer Status Type,” on the contact form. A solution might contain the contact table with the contact form with the new field placed on it. Once distributed from the development environment to another, we will see those new changes in that environment.

Let’s break things down further. Solutions are either managed or unmanaged, each version offering different capabilities. Here are the basic differences:

• You can modify unmanaged solutions. Microsoft considers these as still under development, and you can import or export as unmanaged. You can also export them as managed solutions.
• Managed solutions are complete solutions ready for distribution that you cannot modify after importing them to the selected environment. These solutions are intended for production environments. You can only import managed solutions.

Now let’s dig into how these solutions interact with an environment once imported.

Interactions with Environments

Environments are containers where you store, manage and share your organization’s data, apps and flows. You might have separate environments for development, testing and production. As we mentioned earlier, managed and unmanaged solutions function differently in different environments.

Unmanaged Solutions

An unmanaged solution, once imported, directly modifies the active default solution layer. This active (unmanaged) layer sits on top of any managed solutions and trumps any changes made within those managed solutions. If you delete an unmanaged solution, you delete the group used to contain references to the solution components. You are deleting the “folder” but not the modified objects contained in the folder.

Going back to our example, let’s say we promoted our “Customer Status Type” field in an unmanaged solution to our production environment. If someone requests to remove the field, deleting the solution will not take away the field update. We would need to delete the field from the default layer.

Managed Solutions

Contrary to unmanaged, a managed solution does not share one solution layer and does not modify the default solution layer directly. You install these on top of the default solution and can modify customizable components or add solution components. If you remove the managed solution, you will also remove the solution’s customizations from the environment. You’re removing the “folder” and the customizations within that folder. We will remove our “Customer Status Type” field if we delete our managed solution from the environment.

Managed solutions can layer on top of each other. You will see the latest version’s customizations within the system. Versioning control is especially helpful and necessary when layering managed solutions. Let’s say we need to add an option to our “Customer Status Type” field. The first solution containing the field is already imported as a managed solution into production. We would update the original solution in development, update the version (1.0.0.2), and distribute to our other environments. The latest version would trump the older version in the application behavior.

Using Both Solutions in the Same Environment

Using a mix of managed and unmanaged solutions in an environment is never a good idea. The unmanaged solutions directly change the active default solution layer. Since this default layer trumps the managed solution layers, if you modify and include a component within a managed and an unmanaged solution, it would be difficult to understand which customizations you see and where they originated. It is a best practice to choose one – managed or unmanaged – across an environment.

The following visual shows how solutions interact within an environment:

Next, let’s look at when it’s appropriate to use each type of solution in Dynamics.

When and How to Use Unmanaged Solutions

Ideally, you would only use unmanaged solutions in development environments. They are not meant for you to distribute to production environments. Once you complete an unmanaged solution and it’s ready for distribution to production, you can export it as managed. As we mentioned before, you can still export and import as unmanaged.

It is important to note best strategies for implementations are situational. You can modify your strategy based on the size of the implementation, number of customizations, number of environments, history of what solutions you should have used in the environment, and so on.

You can associate any unmanaged customized component with any number of unmanaged solutions. Whichever solution, including that component you imported last, will directly change the default solution layer. If you delete the solution, those customizations will remain in the default solution. The structure of the solutions is not as important for unmanaged solutions.

When and How to Use Managed Solutions

Microsoft intends that users use managed solutions in production environments with a structured deployment process. When using managed solutions, export the unmanaged solutions from the development environment as managed. If you have a development, testing and production environment, you should only import managed solutions from development into the testing and production environments. As mentioned before, you can only import managed solutions. You cannot export them.

To use managed solutions, export the solution as managed from the development environment. Import the managed solution into the testing or production environment. Remember, when you import a managed solution, it layers on top of the default solution. It does not directly modify the default solution layer. If you remove that solution, you will also remove the customizations within that solution from the environment. Managed solutions layer on top of one another when they modify the same component.

Putting Managed Solutions into (Best) Practice

When working with managed solutions, follow these best practices:

• Use the least number of solutions, all using the same publisher
• Only include components you have modified
• Use versioning control when layering solutions
• Avoid using multiple solutions that modify the same component — If you use multiple solutions including the same component, this could cause solution dependency.

Here’s a real-life example. We had three environments: development, testing and production. We were past Go Live and in Hypercare, meaning end users were fully engaged and using the application daily. We needed to meet auditing standards and be able to track system changes. During Hypercare, our team was ready to fix any bugs that arose. We strived to follow these best practices to create and export the least number of solutions while engaging each component in only one solution. To do this, we followed an object-based solution system. We performed the following change control process:

1. We created a solution with objects we modified in development (a flow, table, field, and so on).
2. We promoted as a managed solution to our testing environment.
3. We tested our modification. If it worked as expected, the solution was ready for production. If not, we updated the solution in development and promoted it to testing again. We needed an updated version to install the most recent version.
4. We promoted to production using the latest version solution file we had successfully tested in the testing environment.
5. We used versioning control when needing further modification.

These steps allowed us to complete the Hypercare stage successfully. We fixed bugs that arose and could easily trace the changes in the system. We could find and document which solution contained which bug fix and met auditing standards.

Conclusion

In conclusion, Dynamics intends for users to use unmanaged solutions within certain environments and managed solutions for others. They interact with the environment differently when imported and, ideally, should never mix in an environment. It is important to understand the interaction and reasoning behind the intention for these solution types when customizing and building out a system to use the best strategy for that implementation.