The trouble with organizing a thing is that pretty soon folks get to paying more attention to the organization than to what they’re organized for.
Laura Ingalls Wilder
I was asked what is the best way to organise customisations in solutions, should I use one solution or many?Like most aspect of development, there are best practices to follow but there isn’t a single best way to do anything which you can use on every project.
There isn’t a best way to organise your CRM solutions because you should organise your solutions the best way for each project, based on the project.
The answer to this question is it depends on the project
In this article I will discuss the different ways to organise CRM solution and the advantages and disadvantages of the different solution architecture.
No Best way
Developers spend hours arguing about the best way to write code, design code, build, deploy and the reason these debates rage on because there isn’t a best way. Some methods are better suited to particular situations but not one suited to every situation.
CRM developers need detailed knowledge of solutions, such as
- What is a managed and unmanaged solution?
- What can and can’t go into a solution
- How do solutions merge together?
- What happens when you delete a managed and unmanaged solution?
CRM 2016 brought in solution patches, which allows you to take part of solution and create a patch of it, copying out a smaller part of a larger solution. For more information on solutions check out the links below
Patches allows developers to update a small part of the CRM solution, create a patch and deploy those changes. Previously if you wanted to update an entity, you had to take all the fields, all the views and other related components for the entity.As with all customisations be consistent in a CRM project.
solutions can cause problems, some common problems are
- CRM 2011 – Solution not importing – Timeout errors
- CRM 2011 – SQL error while importing solution in crm 2011
- CRM2011 OptionSetId Cannot be Changed when Importing Unmanaged Solution
- CRM 2011 – error when importing solution
Solutions can get out of sync because developers added fields on the development environment and QA environment.
Managed solutions problems with out of sync solutions
Out of sync problems can be avoided by using only one route for customisations being created, starting with DEV and flowing through the CRM environments until you get to production.
Questions on Microsoft Dynamics CRM solutions and environments
other blog posts on solutions
- CRM 2013 – Understanding Solutions and how they work
- CRM 2011 – Solutions and publisher prefix
- You can’t import a CRM 2011 solution into CRM 2015
- CRM 2011/2013 – Progress of solution import
- CRM 2013 – Exporting your changes in a solution from your CRM 2013 trial
CRM solutions such as workflows and plugins configuration records in Microsoft Dynamics CRM, if the guid is different between CRM instances the workflow and plugin won’t work.
The blog post below discusses how you can copy data between CRM environments and keep the same guids
CRM 2016 – The importance of keeping the same guids between CRM instances
The article discusses the Dynamics CRM Configuration Data Mover v1.10, a good way to move configuration data between CRM environments keeping the same guids.
Release management and deployments
Solutions are the main mechanism to move customisations from one CRM environment to another, best practices for CRM deployments but these focus on the manual deployment process. Manual deployment process has been used on the projects I worked on because no project manager or CRM practice wanted to invest time in investigating and setting up automated and scripted deployments.
This is a mistake, CRM deployments should use the SolutionPackager and packagedeployer which automate deploying and data, saving developers from the boring task of deploying, reduce errors and remove data errors. This is a gap in my knowledge which I plan to investigate.
If a development task can automated, it should be automated #HoskWisdom
Solution architecture in my experience
Below I list the different methods of organising solution on projects I worked on. These projects were CRM 2011, CRM 2013 and CRM 2015 and before patch solutions.
You can organise solutions to releases/phases/sprints, including the changes for each major release of functionality. During development it’s easy for developers to work with the solution. Developers with experience of the project will find release/sprint solutions easy to understand but new developers won’t find the solution content obvious.
The release solution can lead to many solution files because solutions are not reused but it can stop solution files becoming too large.
- Release 184.108.40.206
- Release 220.127.116.11
- Release 18.104.22.168
- You see what changes were in each release/version/sprint
- You deploy smaller solutions, containing only customisations which changed
- It’s easy to understand
- You can end up with ever-growing collection of solutions
- It can take a long time to create new environments because you need to import each solution in order
- The solutions depend on previous versions
- Solutions can be confusing because they don’t contain all the customisations being used, it’s difficult to navigate to the right customisation
Solutions by customisation type
A few projects organise solution files by customisation type
- Entities and fields
- Custom workflows
- Easy for developers to understand where to put customisations
- The separate solutions are dependent on each other
- More solutions, more time deploying
You just have one solution containing all customisations
- Simple to navigate
- The solution can grow in size and there are some size restrictions
- Potentially complex having all customisations in one solution
- The solution can take a long time to import
- Historically there are problems with solution timing out (before CRM 2016)
Other solution strategies
I haven’t used the solution architecture below but I can see they could be useful in the right scenario
Reusable Solutions (managed)
It’s a great idea to create focused managed solutions for reusable functionality. Functionality like number sequence or a system configuration settings entity would be great to have as a reusable solution which could be used in many projects.
You might need to make functionality generic to fit into it’s own solution, untangling the dependencies from an existing project but the benefits will be you can slot the functionality into any project and potentially sell it to customers.
- Small focused solutions, good programming practice
- Reusuable solutions and functionality between projects
- Maintain a separate solution
- If solution needs to be different you need to branch the solution
If you have a CRM project which will be deployed to multiple CRM instances, it could be for different companies in the same group. The companies could 50 percent of the same functionality and 50 percent different. In this scenario you could have a core solution for the functionality which is the same and separate solutions for the organisation specific functionality.
- Organises the solution logically and easily understood
- Difficult to keep solutions from being dependent on each other
- Lots of solutions to manage and support
Two solutions, one containing system entities and another containing custom entities. I’ve not seen a project use this but I have heard of someone else using it.
- You can keep your custom entities and customisation separate from default entities
- Is this needlessly complex
Futher reading on solution management
I have gone through my experience but I also found this white paper which discusses
ALM for Microsoft Dynamics CRM 2011: CRM Solution Lifecycle Management
Don’t be fooled by the CRM 2011, it is an in-depth analysis of CRM solutions and release management and it was updated in May 2013.
A summary of the white paper can be found here by Blake Scarlavai
CRM 2016 and patching
One of the traditional reasons for creating multiple solutions is large solutions would cause timeout errors when importing. The easiest way to avoid time out problems is to split the solution into multiple smaller solutions.
Microsoft dynamics CRM 2016 include improvements with solutions, removing the need to add System entities and relationships as missing dependencies in a solution. Microsoft added patch solutions, allowing you to import a smaller sub components.
Patches remove the need to create specific hotfix and version/sprint solutions because this is done using patch solutions at a more granular sub component/asset level.
Solutions organised into entities and code (plugins/workflows etc) solutions, the benefit is an organisational benefit and ease of navigation.
How should we organise solutions
There is no one best practice for organising CRM solutions, solution architecture should be based on the requirements for the project.
I like the idea of creating small focused reusable solutions which you can use on various projects, a company could build up a collection of solutions to use in new projects, it would save time and create a standard approach to the functionality spanning projects. This would help to answer the question Why isn’t code reused in Microsoft Dynamic CRM projects?
The solution design of a project rarely creates truly separate solutions and the solutions are dependent on each. Having multiple solutions is a way of organising customisations to move customisations between CRM instances.
There are legitimate reasons for having multiple solutions which could be having a number of CRM instances which need a core solution.
Considering the different options of which solutions you create, for general projects the advantages and disadvantages are similar. There isn’t a definitive winner in terms of advantages but most companies will have a standard way of organizing solutions for general CRM projects (e.g. usually plugins, entities, reports). Consistency will allow developers to work on different projects with least disruption
When assessing how you should organise your solution files you should consider the project, this should guide you to creating the best suited solution organisation for each CRM project.
If the project is before CRM 2016 patching solutions can’t be used, you will need to consider creating smaller solutions to avoid timeout problems.
To save time and efficiency, how you manage your solution is not as important as how you build and deploy those solutions. In a large project with multiple environments a developer can spend hours manually deploying solutions through the various environments.
The SolutionPackager allows you package solutions into XML Fragaments and linked with TFS to automate the build process. This can be used with PackDeployer Automating the build and deployment process using CRM Package Deployer could save hours, reducing deployment errors. The CRM PackageDeployer also packages data, to avoid the manual data deployments and guid problems.
Nice Article Ben! One great bubbling factor, all version knowledge. I love that you reference valid today, valid yesterday information.
there is one issue I come across regularly using the Package Deployer component. If you include everything in one solution, including data, if you have workflows that depend on the data (e.g. Queues), then your workflows will not activate when you import them, and you will have problems assigning the owner of the records to users/teams if they haven’t been assigned security roles.
There are 2 possible ways to get around this.
1) – Consider splitting your solutions down into “Data Model, Security Roles and Shared Web Resources”, “Forms, Views, Dashboards & Form Specific Web Resources” and finally everything else (inc. Plugins, Custom Workflows Activities & Workflows). Use the Package Deployer just for the 1st solution, so that you can include any config data. By the time you get to the 3rd solution, all of your workflows will activate. However, if you need to assign security roles to users or teams as part of deploying your config data, this should be done after the 1st solution, and then import the data (containing the owner field) using the Package Deployer as part of the 2nd solution (instead of the 1st).
2) – Write custom code as part of the Package Deployer to activate the workflows, but consider the other issues around ownership of config data that can also be a real pain.
Hope this helps,
or the third option is you import the reference data as part of your devops process and do it before you import your solutions.