A Scaled out CRM Solution Architecture

Recently I started work on a pretty big CRM project and I wanted to apply a more scaled out approach to my solution architecture.  CRM offers a great facility to deploy code in their solutions but when starting a new project you should always ask yourself the following questions before you starting adding entities into your solutions.

  1. What is the frequency of updates that will be requested by the users and to what components?
  2. Are there multiple users contributing to this project?
  3. How big do you expect this project to grow by?
  4. What kind of promotional model is in place for deployments?

I  have found that questions such as these generally drive the overall solution architecture I will put in place on a project.  For instance, if we are working with a client that has a Development to Production promotion model with only a developer or two on the project, I’ll suggest deploying as one solution.  However, if the project is quite large, has multiple developers on it coupled with multiple deployment stages (which invariably means a more formalized testing process) I’ll tend to go with a more scaled out architecture.

For this current project I went with a component based solution architecture broken out as follows;

  1. Entities – this contains all my core entities, client extensions and web resources.
  2. Security – this contains all my security roles.
  3. Reports – this contains all my custom reporting files.
  4. Workflows – this contains all custom workflows and plugin functionality.

The reason for this approach is to reduce the load on QA and allow the team to install what they need without fear of interfering with the work of others.


Some scenario examples where this should help the team;

  1. When a developer makes a change to only 1 of the solutions, QA can rest easy deploying that single solution (instead of all 4) and not having to regression test all 4 but only 1 solution.
  2. Reports will most likely be handled by developers that are very familiar with developing custom RDL files, as such, they don’t need references to any of the underlying entities and based on user feedback, they will be able to deploy on their own schedule, outside of the core application.
  3. Having security in it’s own solution now opens this up to being managed by non-developer groups (huge).  Although I don’t recommend deploying an unmanaged solution to Production, this solution can actually start it’s “development” or “work” in a TEST or UAT where Business Analysts can create the security roles they think make sense against the new components built by the developer teams without worrying about interfering with any previous development to date.

These are only a few scenarios where I see this architecture helping out in the long-run.  I have gone through a couple of iterations of scaled out architectures from feature to product based but so far this one represents a consistent approach that can be replicated across projects.

My next step will be to minimize any complexity associated with deploying updates to different environments by writing a little component to deploy the correct solution in the correct order.  However as it stands right now, the solutions themselves are quite loosely coupled and can be deployed without error (i.e., reports) without triggering a solution import error.

Creating a New area in CRM 2015 – By Hand

Emphasis on the “By Hand”.  I’d previously blogged about how to modify the Site Map in Dynamics365 with some of the new  ribbon editing features very reminiscent of Ribbon Bench (here for reference Site Maps and Custom Entities – Oh My!) – but recently had the pleasure of having to do this in 2015, with no tools.

The modification of the XML customizations.xml file itself wasn’t too bad on it’s own, where things really became complicated was when I wanted to add an image to my area.

Modifying the Customizations.xml File

To create your new Groups and Areas – check out this post that does a great job of walking you through how to export, modify and import the XML file (along with screenshots).

Adding an Image to your Area

Now where things went off the handle was when I wanted to add an image to my new area.  In order to do this correctly, you need to ensure that the following values all line up exactly including the case and extension.  After banging my head against the wall I noticed that my URL for my web resource did not necessarily have the same display name and some of what it was mixed case.  So I deleted the image, re-uploaded and made sure that all three fields highlighted below.


Lined up with the name being entered here.


After I did this, my solution was again able to import without issue and the image was now being consumed.  Let CRM add in your publisher information, no need to modify that.  After having figured this out, I was able to go back and update the image without issue.

Hopefully this saves you some time.