I was in much debate with myself over the first part of this series. A ‘quick guide’ to four major entities and their interactions can surely be anything but ‘quick’ right? Well, the aim of this post is to be able to focus on the areas that matter, as the whole relationship between the four of these entities can get seriously messed up depending on your business requirement or your imagination. I know when I was learning this I was just like ‘well that doesn’t make sense‘ and when you actually think about it, it does, you just need to keep thinking about it, but don’t over think it. Sounds easy, right? Nope, that’s why this post is a series in many that will really demystify this section of Dynamics CRM and where best to start than to jump right in the middle…

Business Units are Units that make up your Business, including the business itself. However the business is a little bit different to your business units and have different rules that apply.

Upon creation of an organisation in CRM, e.g. ‘CRMCAT’ there is a root business unit created. This is technically, your ‘Organisation’. Your root business cannot be deleted (or you’ll have no organisation, CRM looks after you like that), it cannot be disabled (you don’t really want to disable your business anyway, do you?) however it can be renamed.


Lets turn our picture on it’s head and talk about about hierarchical structure and some light Darwinism.

Its nice to picture your root business unit like a tree or some other rooted structure, and turn it on it’s head, as its easier to visualise the hierarchy but also visualise the  cascading elements of certain parts of these relationships due to the nature of gravity.

CRM CAT business unit structure - grey are business units, green are security roles, orange are teams and navy are users.

CRM CAT business unit structure – grey are business units, green are security roles, orange are teams and navy are users.

Lets say we have our root business unit (our organisation) as CRMCAT. you can see him up there looking chuffed with himself. Now, there are some divisional elements to CRMCAT to allow the organisation to perform effectively and efficiently. These, as with most organisations, are sorted into reporting lines per department.

The first level we have the following Child Business Units of CRMCAT, our root.

  • Off World relations
  • Electrical systems
  • Communications
  • Mechanical (Technical) Department
  • Artificial Intelligence

All 5 of these would be created as business units with their parent business unit as the root: CRMCAT.

For each of these 5 Business Units, a Default Team is created. The Default Team can only be added to when you Create or Modify a User’s Business Unit to specify the business unit relating to that team. I like to understand and classify these types of teams as ‘Default Teams’ (so do Microsoft) and don’t really consider them like your normal Teams. These can be useful so if I have 5 catbots associated to each of the 5 child business units, I would expect to see those 5 users in each of the teams, and if required, records can be easily shared through business units this way.

Next up..

  • A team is related to one Business Unit
  • A user is related to one Business Unit
  • A Security Role is related to one Business Unit at Creation
  • NOTE: A user’s business unit does not relate to a teams business unit. A user can be part of any team with any business unit.

Lets start with Security Roles. Security roles are created under a Business Unit. The ones you get OOB are created under the Root unit. Security roles cascade down the hierarchical structure, so all those available at root, are available to all (as they are directly or indirectly related to root).  They inherit from each other. This is where the Darwinism comes in a bit, it’s just like normal class inheritance really. If i create a new security role at the ‘Off World Relations’ business unit it would mean that only users, teams of that business unit and child business units (and their children) would have access to that security role, and not the other 4. Lets say I create a second security role under the ‘Communications’  business unit,  this means that any team, user created under any other business unit, or child business units does not have access to this Security Role. (However yes, there is an additional behavior we need to take into account, we will cover this in ‘But What If..?’ section)

As my Default Team is really just a team used to group users and business units together we will now create a couple of teams for ‘Off World Relations’ Business Unit:

  • Command (Team) (Business Unit = Offworld Relations)
  • Research (Team) (Business Unit = Offworld Relations)

And likewise, some Teams for the Business Unit ‘Communications’:

  • Improvements (Team) (Business Unit = Communications)
  • Issues (Team) (Business Unit = Communications)

And now we have a couple of new catbots created, User 1, who is under the Business Unit ‘Off World Relations’ on the user record in the lookup, and so appears in the ‘Default Team’ for Off World Relations’.

User 1 has access to the security roles under ‘Off World relations’ directly as you know that users are directly related to security roles. Also any team set to the business unit ‘Off world relations’  also only has access to the security roles that cascade down from the root or other parent business units and ones at that business unit directly. They don’t have access to the Security Role I created under the  ‘Communications’ business unit for example, as it is not made at the root, and ‘Off World Relations’ is not related to the ‘Communications’ business unit (there are rules about making ‘circular’ relationships’).

But What If..’

Lets come back to the rule that: A user can be part of any team with any business unit. This opens up the structure quite a lot, and needs to be considered. User 1 can go and join the ‘Improvements’ Team that has been related under the ‘Communications’ business unit. I have a security role that is directly under ‘Communications’ business unit and so any user or team that is not related to this business unit does not have the option to have this security role. But if this Security Role is applied to the ‘Improvements Team’ and User 1 is added to that team, it means User 1 now has that role that perhaps could give him more permissions than he had before he was a member of that team and that he originally had under the ‘Off World Relations’ business unit and associated teams.

That is enough for one post I think – in the following posts I’ll be creating a more complicated hierarchy, a layered gif info graphic describing the Business Unit/Security Role/Team/User layers and also a Video Demonstration in CRM 2015 over the festive season.