The art and science of asking questions is the source of all knowledge.
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.
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)
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
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
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 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