The art and science of asking questions is the source of all knowledge.
Thomas Berger
I was asked some questions about solutions in Microsoft Dynamics CRM, I decided to answer using a blog post so other CRM developers could benefit. If one person is asking the question there are probably many more people thinking it.
Posting the answer to a question on my blog means other people who are having the same problem can find the answer.
Solutions
Understanding solutions is a something a CRM developer must master, getting it wrong can cause problems deploying and managing your customizations.
The blogs below will give you a good understanding of Solutions, how they work and many of the common problems you experience with solutions (usually managed solutions)
- CRM 2013 – Understanding Solutions and how they work
- CRM 2015 – Best practices for CRM Deployments
- CRM 2013 – Managed solution problems with out of sync solutions
Here are the questions
Q. All changes made to any (unmanaged) solution are applied to the default solution.
A. All changes to an unmanaged solution are applied to the default solutio, you can’t undo the changes except by importing an older unmanaged solution, which is like rolling back those customizations.
Importing an unmanaged solution will overwrite any of the customizations included in the unmanaged solution (assuming the system only includes unmanaged solutions)
Q. Multiple developers are able to work in parallel on the same entities as all changes are applied to the default solution. Everyone has sight of all changes at all times.
A. If you are working on the same CRM environment, changes will be visible instantly to all developers but only published changes will be visible to customers.
- Fields, views, new entities will be visible instantly
- Form changes will be visible when the developer publishes the solution
Code changes are different due to the way CRM developers work e.g. CRM developers tend to download a copy of the code (Javascript or plugin) work on the code and then upload when ready.
Developers usually get the latest code from TFS or the source control used in the project rather than getting the latest code Javascript from the CRM form. This process can result in developers overwriting changes if they are both working on the same Javascript or plugin at the same time because they work offline whilst coding. You can work around this by setting up processes and source control is your friend.
This blog post discuses multiple developers working on web resources
How do multiple developers work on a web resource within the CRM environment
Q. Removing the unmanaged solution does not remove the changes in the default solution – these have to be removed manually (or the default solution can be restored (snapshot tools like Cobalt look good and free? Can they be used to perform a rollback in Dynamics online?)
A unmanaged solution is a wrapper to move your customization’s between CRM environments. When imported it imports those changes into the default solution, overwriting any existing changes. Deleting the unmanaged solution will delete the solution but not delete the customizations.
Managed solutions can be thought of as read only to the customer. You cannot modify any of the managed components (unless they are the default CRM fields). Deleting a managed solution will delete the customizations and the data.
To remove unmanaged customizations you must delete them manually. Solutions are additive which means they don’t remove customizations. You can use unmanaged solutions to change the customizations back to previous state.
I haven’t used Dynamics CRM Snapshot from Cobalt but looking at the page it seems to snapshot the data not the solution and customizations
You can create snapshots of your customizations by keeping the solution files so you can import them to roll them back. Remember to use version numbers otherwise it’s difficult to manage and keep track of the CRM solutions, particularly if you have to move the solutions through multiple CRM environments.
Version numbers are mentioned in the blog post CRM 2015 – Best practices for CRM Deployments–
Q. Managed solutions are essentially a container for any changes you want to move to a new environment. Care must be taken to ensure that all of the relevant changes to entities are pulled into a release. It will become clear when the solution enters UAT if dependencies have been missed.
I have written about Managed solutions CRM 2013 – Managed solution problems with out of sync solutions. Only a solution from the same publisher can update the customizations in a managed solution
Why use managed solutions
Choosing your solution strategy is an important because it can be difficult to swap back from a managed solution to an unmanaged solution. There is anxiety before you make the decision and push the button and import a managed solution.
There are many choices you have to make in CRM which are very hard to undo like
CRM Entity ownership – How do you decide?
I have talked to CRM developers who hate managed solutions and only deploy unmanaged solutions. I have been asked numerous times why anyone would use a managed solution, so lets investigate the reasons.
The logic behind a managed solution is two fold
- Managed solutions are read only to protect the customization creator from users and CRM developers taking and changing the customizations
- Stopping users from changing the customizations which could result in the customizations not working or working incorrectly.
Managed solutions are great for CRM resellers who created a solution for CRM which acts like a products. E.g. an Autonumber solution. They can sell the Autonumber solution, it’s gets deployed and the users can’t change any of the code to stop it working and other CRM developers can look at the code to steal the code/ideas.
This scenario is ideal for managed solutions because if the users change their mind and don’t want to use the solution they can uninstall it and it removes all traces of the solution and its data.
Q. If managed solutions are removed from an environment any data would be removed as well – so we should NEVER remove a managed solution but instead apply a new managed solution on top.
When you remove a managed solution it removes everything
- Customizations
- Data
Once the data is gone you can’t get that back, which is why you need to think carefully if using managed solutions are the right choice.
I know many CRM developers who refuse to use managed solutions due to
- Build problems
- unable to edit production/live system without importing a new solution
- Solution dependencies
Unmanaged solutions will give you an easier life but it will potentially let end user modify live customizations which could break the solution and with no easy way to know what had been changed.
CRM 2016 has added patched solutions
- Solution Patching in Microsoft Dynamics CRM 2016
- Dynamics CRM 2016 Cloning Solutions & Patches
- CRM 2016 Solution Segmentation for The Rest of Us
Solution patching allows you to release smaller solutions, creating smaller solutions and reducing conflicts and problems when deploying the patch solution.
I haven’t used patch solutions so I don’t know if the theory works in practice.
Q. Environments setup question
Dev – unmanaged default solution with project related solutions.
UAT – Test environment that managed solutions are deployed into.
Live – managed solutions transition to prod when successfully passed UAT.
There is no right answer for the number of environments, it depends on the development and testing schedules you are doing, how you work with the customer.
The number of environments can reflect the different phases of a project, you can often have testing and development phases running at the same time.
Ask yourself what is the purpose of each environment.
I would add a preproduction environment, an environment which is hosted on the customers site or a sandbox instance if using Microsoft Dynamics CRM online. This environment has exactly the same customizations and similar data to the production environment. It allows the customer to test near production environment and is useful for investigating live issues.
For on premise development it’s common to have a development environment and internal QA/UAT environment for non developers to test fixes. Developers are terrible at testing their own fixes
The usually test as CRM Admin role – The System Administrator role is a benefit and a curse to CRM developers
They often only test the happy path –Don’t just test the happy path
Development environments have development data – How to create realistic Test Data for your CRM Project and why you should
Here is some final reading on CRM environments for you – The pain of setting up CRM Dev environments
Hosk's Dynamic Blog 
Hi Hosk
In the 3rd question, Paragraph “Unmanaged solutions can be thought of as read only to the customer. You cannot modify any of the managed components (unless they are the default CRM fields). Deleting a managed solution will delete the customizations and the data.”
Should it start “Managed Solutions can be …”
LikeLike
Thanks Dave, I have fixed it
LikeLike
Hi Hosk. Great post! Is there in some Microsoft documentation something that says it is a good practice to use Unmanaged Solutions in the DEV environment and when we proceed to production environments we use Managed Solutions?
LikeLike
Probably but I’m not sure where it might be, reading the msdn article on solutions is a good start – https://msdn.microsoft.com/en-us/library/gg334576.aspx
LikeLike
That’s it. I had already found this sentence:
“There are two types of Microsoft Dynamics CRM solutions: managed and unmanaged. A managed solution is a completed solution that is intended to be distributed and installed. An unmanaged solution is one that is still under development or isn’t intended to be distributed. When the unmanaged solution is complete and you want to distribute it, export it and package it as a managed solution.”
I think this will be the closest to what I’m looking for.
LikeLike
I view managed solutions as read only and unmanaged as editable. If you don’t want end user potentially changing you solution then making read only stops them.
if you were selling a solution you would make it managed to stop people stealing your customisation.
LikeLike
Hi Hosk. I am customising a managed solution provided by another vendor. They say that it I export & import my customisations as an unmanaged solution (from DEV to PRODUCTION), that this might cause problems when the vendor next sends a solution upgrade. Specifically they say that if I customise a form and then they update the form, their updates might not appear – because CRM thinks of the form as unmanaged because of my customisations. They recommend that I create my own managed solution for updates to the PROD system. Does this sound right to you or should I stick with an unmanaged solution? I think that I’ll still have the same issues with customisations whether or not my solution is managed. I currently have an unmanaged solution in PROD that I want to update. What do you think the consequences will be if I export and import from DEV as a managed solution – will CRM convert the unmanaged solution in PROD to a managed solution?
LikeLike
The problem of customisations being over written can happen if it’s managed or unmanaged. The changes will merge for some customisations e.g. adding new fields but for other changes like forms then the last change will win and over write.
I would create your own solution to keep track of your changes. Whether it’s managed or unmanaged is up to you.
In CRM you often need to have the same publisher to update managed solution components, unless they are default entities.
You can convert prod to managed if you want, delete the unmanaged and import a managed.
You want to think about doing this because managed solutions mean you cannot edit any of those components on prod without importing the changes and if you delete a managed solution it will delete all the data
LikeLike
Thanks for the reassurance Hosk. I’ll stick with an unmanaged solution at this stage.
LikeLike
Dear Ben,
Your blogs are great learning path for many of the beginners like me.
Could you please post an article on best practices for managing solution between different environments like development to sandbox or production, considering the new option such as patching, cloning etc…
Even though many documentation on these are available, I hope your experience can add more value to this.
LikeLiked by 1 person