Myth of Managed Solution in the Power Platform

Solutions is the key component for Dynamics CRM since CRM 2011 that moves the deployment process from environment to environment. If we talk about the solution, then it is defined as a container that contains various components (for example, table, sitemap, column, process, plugin and others). When the solution comes to mind that there is no confusion, we fully believe that this container will aid in component movement from one instance to another.

A solution is a container for the components of an application that acts as a transport unit to enable applications to move between environments.


But the optimization of unmanaged and managed solutions always poses a dilemma for standard practices. The CRM/CE world is always in a state of confusion as to which is best for their deployment process. This is the best interview question for interviewer about solution behavior and best selection solution types. In addition they also want to know about the modification of managed solutions. In this article, I will talk about only Managed Solution.

In Microsoft's view, the Managed Solution that is intended for distribution only.

As for Microsoft's Word, this is for ISVs or to protect intellectual property during distribution, but the question remains, why should developers care about a managed solution? The solution as we know it, was introduced in Dynamics CRM 2011. Gradually it has become a part of the development process. Developers usually confuse which one is best for their development process, either it is unmanaged or managed solution?

When a solution is packaged as a managed solution, the form definitions stored in FormXML are compared to the original FormXML and only the differences are included in the managed solution. When the managed solution is installed in a new environment, the form customization differences are then merged with the FormXML for the existing form to create a new form definition. This new form definition is what the user sees and what a system customizer can modify. When the managed solution is uninstalled, only those form elements found in the managed solution are removed.

The special thing to note here is that the managed solution is maintained separately while the unmanaged solution is merged with the default solution, as a result, if we uninstall the managed solution, it will be deleted all data with the customizations. The deletion of Unmanaged Solution, it removes only their structure, but their components and data exist with the default solution.


If we export a managed solution from one organization and import it to another, we can’t edit the solution in the new organization.

It means managed solution is locked and unable to add/edit/remove/edit/export components, of course this mechanism protects intellectual property, but below few questions arise in mind:

  • If we need to replace the current feature in new business scenarios.
  • Distributor/Vendor/ISV has closed its business.
  • The solution provider is acquired by different company.
  • How to upgrade this feature to the upgraded version of Environment.

Microsoft recommends the following methods for customizing managed solutions:

Managed Properties :

A managed solution cannot be customized to the target organization. But, using the concept of managed properties we can define whether the solution component will be customizable or not and if so, what specific parts of the component will be customizable once the solution is exported as a managed solution.



Patch: 

  • The patch solution is applied to either a managed or unmanaged solution and only includes changes to entities and associated entity properties.
  • We can create patch from parent solution using "clone as patch" and patch solution cannot be patch solution.
  • We cannot install unmanaged patches to manage base solutions. It must match the type of base solution.
  • We cannot remove a component from a solution using a patch if the components need to be supported, added or updated.
  • The version number of the patch should have the same major and minor number, but we should update the build and release number every time we deploy a new patch.
  • The patch solution type feature is available as of CRM version 8.0 or higher.

My view for adoption of Managed Solution:

  • It is a bad idea to use a "managed solution" to use a transport unit for tables and columns, as customizations are restricted and data will be deleted when the solution is uninstalled.
  • To adopt a managed solution, we need appropriate application lifecycle management and best practices for implementing a managed solution, as it is too restrictive to change, as a result, minor changes or bugs can be costly matters for the organization.
  • To use proper version control, as missing or missing code/customization can be a hindrance to growth or new development.
Summary:

In my CE/CRM experience, I have never used a managed solution, but I want to use a managed solution, but it demands high discipline, planning and monitoring to implement a managed solution. Where managed solutions are used, there is greater control and this enforces discipline and governance.
I personally would start with unmanaged within DEV and then have a separate source control repository to track different versions of solutions and use the managed solution within production and other instances leading to production.

Comments

Popular posts from this blog

Exploring the Differences: Managed vs. Unmanaged Solutions in Dynamics CRM/Dataverse

PCF vs. Web Resources: Choosing the Right Extensibility Tool for Dataverse

Effective Strategies for Debugging Plugins in Dynamics CRM