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.<\/p>\n
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\u2019s start by looking at the definitions.<\/p>\n
Solutions: Unmanaged and Managed<\/h2>\n
First, let\u2019s look at what solutions are in general. Solutions enable developers to package and maintain their customizations for Microsoft Dynamics 365 Customer Engagement<\/a>. Customizers and developers distribute solutions so organizations can use D365 CE to install and uninstall the custom business functionals determined by the solution\u2019s content.<\/p>\n To put it another way, compare a solution to a folder holding within it built-out objects that we can distribute.<\/strong> For example, let\u2019s say we have our development, testing and production environments stood up. We have a request for an additional field, \u201cCustomer Status Type,\u201d 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.<\/p>\n Let\u2019s break things down further. Solutions are either managed or unmanaged, each version offering different capabilities. Here are the basic differences:<\/strong><\/p>\n Now let\u2019s dig into how these solutions interact with an environment once imported.<\/p>\n Environments are containers where you store, manage and share your organization\u2019s data, apps and flows. You might have separate environments for development, testing and production.<\/strong> As we mentioned earlier, managed and unmanaged solutions function differently in different environments.<\/p>\n 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 \u201cfolder\u201d but not the modified objects contained in the folder.<\/p>\n Going back to our example, let\u2019s say we promoted our \u201cCustomer Status Type\u201d 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.<\/p>\n 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\u2019s customizations from the environment. You\u2019re removing the \u201cfolder\u201d and the customizations within that folder. We will remove our \u201cCustomer Status Type\u201d field if we delete our managed solution from the environment.<\/p>\n Managed solutions can layer on top of each other. You will see the latest version\u2019s customizations within the system. Versioning control is especially helpful and necessary when layering managed solutions. Let\u2019s say we need to add an option to our \u201cCustomer Status Type\u201d 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.<\/p>\n 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 \u2013 managed or unmanaged \u2013 across an environment.<\/p>\n The following visual shows how solutions interact within an environment:<\/p>\n\n
Interactions with Environments<\/h2>\n
Unmanaged Solutions<\/h3>\n
Managed Solutions<\/h3>\n
Using Both Solutions in the Same Environment<\/h3>\n
![\"Managed](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2023\/03\/blog_EAS_Managed-Versus-Unmanaged-Solutions-1024x536.jpg\")
<\/a><\/p>\n