CRM 2016 – What’s the best way to organise solutions in Microsoft Dynamics CRM

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.

Writing plugins in Microsoft Dynamics CRM has many best practices such as using early bound code, I would argue in most cases you should use early bound code, it‘s easier to read, it captures validation errors and has minimal effect on the size and execution time of the plugin.  There are times when it‘s good practice to not use early bound code when you write a plugin which will be triggered by multiple entities.  It depends on the requirements.

Solutions

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?

To learn about solutions read my post Overview of solutions

and msdn – Introduction to solutions

Solution patches

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

• Create patches to simplify solution updates
• Use segmented solutions and patches to simplify solution updates
• Solution Patching in Microsoft Dynamics CRM 2016
• CRM 2016 Solution Segmentation for The Rest of Us

This video from Dynamics CRM tip of the day walks you through patchesPatches allows you to choose components and sub-components.  This allows you to select individual fields and not all fields, reducing the time to deploy and potential conflicts.

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.

Solution problems

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.

you can find common questions on solutions in thetwo blog posts below

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

Guids

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.

Release/version/sprint 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 2.1.1.1
• Release 2.2.1.4
• Release 3.1.1.0

Advantages

• You see what changes were in each release/version/sprint
• You deploy smaller solutions, containing only customisations which changed
• It’s easy to understand

Disadvantages

• 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
  • Entities and fields
  • Lists
  • Forms
• Code
  • Javascript
  • Plugins
  • Workflows
  • Custom workflows
• Reports

Advantages

• Easy for developers to understand where to put customisations

Disadvantages

• The separate solutions are dependent on each other
• More solutions, more time deploying

One Solution

You just have one solution containing all customisations

Advantages

• Simple
• Simple to navigate

Disadvantages

• 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.

Advantages

• Small focused solutions, good programming practice
• Reusuable solutions and functionality between projects

Disadvantages

• Maintain a separate solution
• If solution needs to be different you need to branch the solution

Core 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.

Advantages

• Organises the solution logically and easily understood

Disadvantages

• Difficult to keep solutions from being dependent on each other
• Lots of solutions to manage and support

System/Custom Solution

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.

Advantages

• You can keep your custom entities and customisation separate from default entities

Disadvantages

• 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.

The improvements in CRM 2016 and patching means the common problem of solution timeout isn’t an issue.

Conclusion

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.

Advertisement