The art and science of asking questions is the source of all knowledge.
I was asked some questions about solutions in Microsoft Dynamics 365, I decided to answer using a blog post. 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.
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
- Dynamics 365 — Problems with managed solution problems 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 solution, 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).
You have to manually delete unwanted changes in managed 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 Dynamics 365 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
This blog post discuses multiple developers working on web resources
Q. Removing the unmanaged solution does not remove the changes in the default solution — these have to be removed manually or backup resorted.
A unmanaged solution is a wrapper to move your customization’s between environments. 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 are read only and sit in a layer above the default solutions. You cannot modify a managed components. 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.
Managed solutions can delete customisations by using a holding solution
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 Dynamics 365 — Problems with managed solution problems out of sync solutions. Only a solution from the same publisher can update the customizations in a managed solution.
Why use managed solutions
You can convert an unmanaged to a managed solution but you can’t convert a managed to an unmanaged easily. How to convert an unmanaged solution into a managed solution in Dynamics 365?
There are many choices you have to make in Dynamics which are very hard to undo like Dynamics 365 Entity ownership — How do you decide?
I have talked to developers who hate managed solutions and only deploy unmanaged solutions. some developers ask why would anyone would use a managed solution, so lets investigate the reasons.
Microsoft recommends using managed solutions beyond the development environment. This post — Application lifecycle management on ALM maturity, Microsoft states
Are you deploying managed solutions? Managed solutions are how Microsoft intends for solutions to be deployed to environments beyond development. All ALM tooling and solution features from Microsoft to support deployment will be targeted toward this goal.
The logic behind a managed solution is two fold
- Managed solutions are read only to protect the customization creator from users and developers changing customizations
- Stopping users from changing the customizations which could result in the customizations not working or working incorrectly.
Managed solutions are great for resellers who created a solution for 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 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, data would be removed as well
When you remove a managed solution it removes everything
Once the data is gone you can’t get that back (There are hourly backups of your environment for the last week), which is why you need to think carefully if using managed solutions are the right choice.
Some developers refuse to use managed solutions due to
- Build problems
- unable to edit production/live system without importing a new solution
- Solution dependencies
Unmanaged solutions can cause environments to be different and out of sync, this can hide bugs and invalidate testing. I want all environments beyond dev to be the same.
The article below discusses ways you can organise your solutions.
Q. Environments setup question
- Dev — unmanaged default solution with project related solutions.
- Dev Master — deployment of your customisations ready for ALM tool to deploy/put in source control etc.
- UAT — Test environment that managed solutions are deployed into.
- Live — managed solutions transition to prod when successfully passed
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 have testing and development phases running at the same time.
What is the purpose of each environment?
A preproduction environment allows you to copy production and investigate production problems you cannot replicate in other environments.
For on premise development it’s common to have a development environment and internal QA/UAT environment for non-developers to test fixes.
Developers usually test as Admin role — The System Administrator role is a benefit and a curse to Dynamics developers and miss security bugs.
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