What’s the best way to organise solutions in Microsoft Dynamics 365

Image for post
Image for post

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

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 solutions because organise your solutions the best way for each project, based on the project.

I will discuss the different ways to organise solutions and the advantages and disadvantages.

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 365 has many best practices such as using early bound code because it‘s easier to read, it captures validation errors in design time and not run time. 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.


Dynamics 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?
  • 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

Patch solutions allow 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

This video walks you through patches. Patches 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 solution, create a patch and deploy those changes. Previously if you wanted to update an entity, you had to take allthe fields, all the views and other related components for the entity.As with all customisations be consistent in a project.

Solution problems

solutions can cause problems, some common problems are

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 Dynamics environments until you get to production.

you can find common questions on solutions in the two blog posts below

Questions on Microsoft Dynamics CRM solutions and environments

other blog posts on solutions


Dynamics 365 solutions such as workflows and plugins configuration records in Microsoft Dynamics CRM, if the guid is different between Dynamics 365 instances the workflow and plugin won’t work.

The blog post below discusses how you can copy data between Dynamics 365 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 Dynamics 365 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, Dynamics 365 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
  • Release
  • Release
  • 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
  • Entities and fields
  • Lists
  • Forms
  • Code
  • Javascript
  • Plugins
  • Workflows
  • Custom workflows
  • Reports
  • Easy for developers to understand where to put customisations
  • The separate solutions are dependent on each other
  • More solutions, more time deploying

One Solution

You just have one solution containing all customisations

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

Core Solution

If you have a Dynamics 365 project which will be deployed to multiple Dynamics 365 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

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.

  • 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 Dynamics 365 solutions and release management.

A summary of the white paper can be found here by Blake Scarlavai


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 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 benefitis an organisational benefit and ease of navigation.

How should we organise solutions

There is no one best practice for organising Dynamics 365 solutions, solution architecture should be based on the requirements for the project.

I like 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 saves time and creates 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 separate solutions and the solutions depend on each. Having multiple solutions is a way of organising customisations to move customisations between Dynamics 365 instances.

There are legitimate reasons for having multiple solutions which could be having a number of Dynamics 365 instances which need a core solution.

Patching means the common problem of solution timeout isn’t an issue.


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 Dynamics 365 projects (e.g. usually plugins, entities, reports, workflows). Consistency allows developers to work on different projects with minimal disruption

When assessing how you should organise your solutions, think about what you are trying to acheive and don’t forget you can always change it in the future.

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.

Written by

Have been working with Dynamics 365 since version 4 and enjoy reading and delivering enterprise projects

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store