What’s The Story
There are two types of solution in Microsoft Dynamics 365.
Managed and unmanaged.
Which one should be used in any given situation is up for debate (no it really is). On one hand you have Microsoft saying that unmanaged should be exported as Managed when targeting any instance which is not the development environment typically meaning UAT and Production.
This is part of the ALM guidance which is only 76+ pages so enjoy the read. I’m going to try and keep this article snappy to give you the main considerations and background to the whole managed vs unmanaged debate based on my practical experience of using both approach in CRM implementations.
Understanding Solution Levels
Any dynamics 365 instance has the following layers or levels:
- System Layer
- Unmanaged Layer
- Managed Layer
System layer is known as the “default solution” it contains all out of the box customisations, so is the vanilla instance if you will of a CRM instance once provisioned. Now, when we create unmanaged solutions, we are creating a container or view into the default solution, the solution itself (or the reference) is stored in the unmanaged layer but understand, as they are unmanaged solutions, we are effectively modifying the default solution. This means that an unmanaged solution cannot be uninstalled. I think of unmanaged solutions as “a view” into the system or if you like the source code of the solution and a managed solution is the assembly. If you delete a unmanaged solution, it will only delete the reference entry in the unmanaged layer, the customisation remain in the default solution.
A managed solution on the other hand is non-editable though some managed properties can be set, they (and their specific customisations) can also be uninstalled (mostly) from the system. Managed solutions can be layered (stacked) on top of each other so in a sense provide version control. How effective is that version control? Why would we want cross solution dependencies (layered functionality)? How easy is it to update a managed solution in a target instance especially if the customer breaks or changes something directly in those environments? All are separate considerations when looking at the listed pros and cons of each approach.
The Cumulative Nature Of Solutions
As the header states, whether managed or unmanaged, they effectively make additions to the platform as we are customising the system either at the system layer or managed layer. For this reason, if something new is added to the system it can never be completely removed (there are fragments of it left in the metadata) but what is true is that if you delete a component/attribute/relationship in an unmanaged solution it will be removed from the platform vs. not having that option if you deployed as a managed solution. Did you get that if not read the last line again… you can not delete anything when you deployed as managed. That should signal alarm bells if you are NOT an ISV and are for example working in an Agile environment on a Dynamics 365 implementation.
Managed Solutions Overview
Managed solutions are “cumulative” even if you overwrite a managed solution with a newer version it will not remove the old components or change that metadata. The only way to remove components is to uninstall the managed solution completely however that will also drop any reference or user data that you may have previously imported (I’ll touch on the holding workaround and Dynamics 2016 new features later on). A managed solution funnily enough means everything is well err managed so that means components such as:
- Entities
- Javascript
- Views
- Attributes
- Relationships
- Forms
- Option Sets
Will not be removed, even when they are not included in an updated managed solution version. Also you can not go in there and manually delete managed components directly so all of those old relationships, attributes and the rest will sit in the system bloating it over time. Managed solutions can also be a nightmare when you are looking to update them with a new version especially if you have removed things like relationships from dev and then try to import conflicting changes.
Which One Should Be Used
There are a few key things to consider. Managed solutions really were created so that Microsoft Partners/Independent Software Vendor (ISV) had a means to protect their IPR, package up and sell solutions to the market along with the means to issue updated versions in a controlled way. The official line is that a mature customer would want a robust and version controlled release cycle and so managed solutions (in theory) provide this capability as they are layered and you can’t edit them or remove directly in the target environments (without completely uninstalling).
Scratch that for a second, take note “Ever noticed in life there is often a big difference between what one should do as deemed to be best practice vs. reality of what actually happens?”.
I’m going to summarise when one is preferred over the other… here goes:
- Use Managed solutions if you are a ISV and plan to release to the market place.
- Use Unmanaged solutions where you are working on an ever-changing platform meaning customisations are happening all the time so it is not a fixed deployment.
If you can’t trust the development team to update solution versions before export, check-out and check-in code into TFS or whatever code repository you have in place and follow a good release practice then I would argue that’s a fundamental issue outside of whether to use managed or unmanaged solutions. Restricting a deployment and adding technical complexity is not the answer.
To me, it seems to come down to a couple of things namely “trust” and “paranoia”. You need to trust that developers are not silly enough to go and customise the system in UAT/Production thereby causing issues the next time one tries to import a solution. You also would ensure that the customer has the security roles appropriate to their level of knowledge.
If you have a team of developers all working on CRM, chances are you may not even have a “core solution” because that would be huge and take ages every time you wanted to deploy or customise the application ribbon. Once the core CRM has been customised and released to Production, chances are there will be multiple maintenance type sprints a decision would be needed on whether to have the one main solution or to have multiple unmanaged solutions representing the sprint and user story (separate article on that one!) which you would deploy individually to UAT and then Production in the right order.
Add to this mixture, the problem of then having to work with Managed solutions across UAT and Production environments.
In a nutshell, using managed solutions adds more complexity to the development and release process for very little gain (unless you are a ISV).
Now in Dynamics 2016, to be fair Microsoft has added functionality so you can be very specific on what customisations should be included in a solution, along with patching, cloning and a stage for upgrade option, so this helps with reducing potential conflicts and dependencies that would otherwise cause a solution import to fail. Wonderful… but guess what, that is still adding more complexity to the release process. Holding solutions can also be used to help with data retention when looking to drop old components or fix any conflicting issues.
In my experience, there doesn’t appear to be a “right” or “wrong” answer to the question. I personally always go with the Microsoft/best practice recommendations but quite honestly, I have only ever seen managed solutions make implementations more complex for both the customer and development team for “zero” benefit. If there is good communication in the team, appropriate security models setup for the customer and fit for purpose release and development processes one can avoid the pain of managed solutions by addressing the real issues and project challenges head on.
Further Reading
http://www.crmconsultants.co.uk/managed-vs-unmanaged-solutions/
http://www.crmconsultants.co.uk/improving-release-management-with-solutions-in-dynamics-crm-2016/
http://gonzaloruizcrm.blogspot.co.uk/2012/05/crm-2011-deleting-attributes-entities.html
http://gonzaloruizcrm.blogspot.co.uk/2012/01/managed-or-unmanaged-solutions-in-crm.html
Antony Ellis Dynamics 365 CRM 
4 Pingback