Dynamics365 is not a Database

Yes, it has a database that stores all of it’s information within it, but it is not a database.

Similar to Skype For Business and SharePoint that have databases to store all of it’s configuration models and user data within it, they are not referred to as databases.

Over the years I’ve been asked many times to take a customer’s existing database model and map it to Dynamics – i., pick up and replace.

This generally leads to a back and forth on how this should be done as we discuss legacy information, schemas that no longer apply or are used and features that can simplify the overall implementation of the schema.

I think part of the reason for this is the readability of the Dynamics schema whereas something like SharePoint and Skype For Business is much more obscured (or a bit harder to read) whereas Dynamics can be readily mapped to the SDK.

When “migrating” a schema it’s important to remember;

  1. Your current schema for state engines will be replaced with State/Status codes for Dynamics.
  2. Your user ownership will be replaced by createdBy/modifiedBy entries tied to an active directory (on premise or in the cloud) and not use application Ids.
  3. Many-2-Many tables will exist in Dynamics but will not necessarily be accessible to you.
  4. Auditing is a checkbox that you enable.

I think what would really benefit Dynamics in this regard, and where I feel the Solution Designer falls down, is not providing a proper Entity Relationship Model for both the logical and physical implementation.  When talking with end users, it’s the logical they are more concerned with – “are all of our concepts within there” – and the developers who are more concerned with the physical – “can I get all my datatypes and fields in there”.

In the end, I urge customers not to think of their Dynamics implementation as database with an application on top of it, but instead of a platform that are creating, extending and debugging.

No code I know, but had to get this out there – it’s not a Database!

VSTO – Enabling Ribbon Controls at RunTime

I recently ran into an issue where I needed to enable and disable Ribbon controls in a VSTO plugin where the Ribbon controls were initialized through a Ribbon.xml file.

This can be a bit challenging s the controls in the Ribbon XML file are not available to your code at design time when you are trying to write the actual code.

In addition, I needed to trigger the decision handling logic from another section of code not associated to the Ribbon.

Accomplishing this task involved a number of steps and was done building an integration to Outlook (not sure if this would be similar in Word or Excel).

Identify the controls at run-time

In each control that I wanted to control the state on, at the time of the Ribbon’s instantiation I had them call the “getEnabled” property which called a function that enabled them all and stored an instance of that control in memory for later use.

<labelControl id="lblMyLabel" label="This is My Text" getEnabled="setState" />

In code, I then had a simple List<IRibbonControl> collection created that stored this information.

Note: If you are dynamically adding controls at runtime this could be complex.

Implementing Decision Logic

I won’t go too deep here as every application has their own applicable set of logic but for me a simple eventing framework where I could Fire a State change from any part of my application and subsequently have my ribbon handler listen on the event at start worked perfectly for me.

Changing State

In my aforementioned event, the control determined when to fire a state changed event and thereby would send to the whether the Ribbon should be enabled or disabled.

When receiving the event, it was a simple matter of invalidating the current control on the ribbon and calling the initial state handler that was tied to be ribbon control to reset it’s enabled or disabled status.

foreach (IRibbonControl ctl in _controls)

In doing this, I had 5 controls as part of ribbon – textboxes, labels, buttons and checkboxes and they all worked perfectly.

This was a little more roundabout than I would have liked but I’m happy with the results and consistent implementation.  If I decide to add new controls to my ribbon, all I need to do is ensure the getEnabled property is subscribed to and the state handler will take care of the rest.


Creating Your Own Business Unit

Business Units are one of those dicey concepts in Dynamics where if done right – they make sense and are of big value to your implementation.

But when done wrong, they can be a black hole that makes your life very hard to recover from.

When discussing with clients why they need a business unit there are a few things I generally look for;

  • Do you have groups within your organization that need to keep their data separate from one another?  The best example being a parent company with subsidiaries which need to use the same system but cannot see each other’s data (because they are partners).
  • Are you trying to do implement security with a Business Unit (i.e., what people can and cannot do?).  If so, you should look at security roles.

Generally, when implementing Business Units, I encourage customers not to go too many levels deep in their first implementation.

On a recent project, I had to some solution deployment code and wanted to figure out how to create a Business Unit from the SDK.  The key to the creation of any business unit is the hierarchy so the first thing you need to do is get the reference to the parent business unit id where you want your business unit to reside in.

Once you have done that, it’s as easy as creating the business unit code, assigning the new EntityReference and creating the object.

QueryExpression query = new QueryExpression("businessunit")
ColumnSet = new ColumnSet(true)

EntityCollection businessunits = cn.CrmService.RetrieveMultiple(query);
if (businessunits.Entities.Count == 1)
Entity busunit = new Entity("businessunit");
busunit["name"] = "Test Greg Unit";
busunit["parentbusinessunitid"] = new EntityReference("businessunit", new Guid(businessunits[0].Attributes["businessunitid"].ToString()));


Now obviously not the cleanest code but it does show you how easy it is to create a business unit.  If I was going to be more elegant about this code, I would be evaluating the parent unit on some additional criteria in my code and not simply be taking the first one that comes down.

Interestingly enough, when you run this code a second time, the primary business unit (the parent) now comes down with 9 attributes, whereas the one that I created has 17, so that could be an interesting keying off point as well.

More to dig into.

Do you still Customize the Default Solution?

Since the introduction of the solution framework in CRM 2011 (and now Dynamics365), I have not customized the default solution and find no value in doing so going forward.

Apart from their deployment and product shipping functionality, solutions provide a container where I can specifically look at what I am customizing and am working on as it pertains to my own entities.  Whether it is an unmanaged solution in Production or Development (hopefully not in Production), at the very least I have a container that takes me two minutes to create that nicely encapsulates all the changes I have made.

With the Default Solution, I see the world, everything that is in it and everything that is a part of it.  If I were to step away from this solution for a month or two and then come back to it, I would have to think hard about what I had modified and where.

And this is problem the worst part about the default solution is that it allows these changes to be introduced into a Production environment without anyone but that Administrator knowing what, when and where the change was made.  I’ve been in a few environments where we have worked on a solution, tested it and stamped it – only to have users complain that they are missing functionality from the latest release because there was a conflict with the default solution.

Even as a single developer on a small Dynamics system; take the time, plan for the growth of your solution and encapsulate your code into unmanaged solution at the very least.

You’ll be that much happier for it when your system starts to scale and grow.