CRM 2013 – MB2-703 – Business Units and Security Roles Study Information

15 percent of the exam is based around security so you need to know it and know it good.

In this blog I will cover one part of the security concepts

This topic may include: describe Business Units; describe Microsoft Dynamics CRM security features; describe privileges and access levels

I have found 3 blog posts which I often find my way to when searching for CRM Security.  So I would recommend you go through those because they will give you a good idea how security roles work in CRM 2013, links to them can be found in the blog post below.

To learn about security and business units the best way is to get into your CRM trial and try adding business units and security roles.

First have a good look

second get in there and add some new business units and security roles

thirdly get renaming and deleting them

I will run through this in the video but I recommend you do it yourself, this will help cement the knowledge into your brain and provide more paths to the information (which means you will be able to recall it easier in the exam, yippee).  The blog post and the video work together, the video shows you security roles and business units in CRM and the blog post is a succinct summary of it.

 

I am only going to skip through what I think are the vital points, I expect you to read the three blog posts below, watch my video explanation and have a play in your CRM trial

I will first start with this great table from the power objects blog, this is a good introduction to security

http://www.powerobjects.com/blog/2014/02/14/microsoft-dynamics-crm-2013-business-units-and-data-silos/

 

To help understand how this works, consider the following definitions of the Dynamics CRM security components:

Component	Description
Business Unit	A scoping mechanism that defines a grouping of users for security modeling purposes; business units are hierarchical in nature. Business Units are a framework upon which a security model is built.
Security Role	A collection of privileges (that are given a name) that reflect common user roles of your organization and/or business units; security roles are assigned to users or owner teams. See below for more details on Security Roles.
Privilege (access rights)	The definition of a specific type of data access or action that can be granted as a right; privileges are granted through a security role and are cumulative. The following Privileges that can be assigned: Create Read Write Delete Append Append To Assign Share
Access Level	While the Privilege defines the type of data access, the Access Level defines exactly to which records the privileges apply. You can assign the Access Levels of: None User Business Unit Parent: Child Business Unit Organization For example, if you assign Read privileges to a Security Role at the Access Level of “Business Unit”, users with that Security Role will only have the privileges to see records owned by a user within their Business Unit.

Business Units

As you can see the security in CRM is created from a few pieces of functionality working together.  You have business units and security roles, within these you have privileges and access levels.

Access level controls what the user can see(read)/edit

Privilege controls what you can do to the entity

 

It all starts with business units and the Parent Business unit which is also known as the Root business unit, you can think of this as the mother of all business units.

The Root business unit is a default business unit which has the same name as the organisation.

You cannot delete the Root business unit, you cannot disable it

You cannot create a business unit above the Root business unit, e.g. you cannot give it a parent.

 

Business Units = Tree Structure

Business units are used to create a hierarchy and this is in a tree structure.  The Root business unit will be at the top.

Here are two examples of some very simple Business unit structures.  The common way people use business units is geographical or departmental, although you can split up your organisation and business units anyway that suits you.

Here is a geographical structure

 

Here is departmental

 

You can see from the pictures above that the business units have create a hierarchy and the root business unit is at the top.

 

What can you do to Business Units

Classic certification questions usually revolve around what you can and can’t do in CRM.  Examples of things they will test

You cannot delete or disable the root business unit

you can rename, disable non root business units (e.g. all the other business units)

 

Disabling Business Units

You need to know what happens when you disable a business unit, what happens to all the users who have that business unit as their default business unit?

When you disable a business unit, it also disables all the child business units below it (and thus all the users who those business units as their default business unit).

none of the data is affected by disabling business units, its only the users who cannot then log in but it is important to take into account all the child business units will also be disabled.

The users are not disabled but cannot login into CRM whilst the business unit is disabled.  As soon as the business unit is enabled they will be able to log into CRM again.

Deleting Business Units

It’s possible to delete business units (not the root business unit) but you have to clear them up ready to be removed.

Firstly you have to disable the business unit and you can only do this when

you have removed any the child business unit, now you can either disable and delete them or you can re-parent them.  To re-parent a business unit you can select a new parent business unit.

If you re-parent a business unit this will have the effect of removing all the security roles from the users, this is because security roles are inherited and can be different in each business unit.  This will mean all the users in the business unit you are re-parenting will now have no security roles and won’t be able to log into CRM.  This is explained by an excellent comment by CRM MVP Adam Vero (also a CRM Master)

if you want to delete the business unit then you will need to change all the users/teams that are assigned to that business unit.  You also need to disable the business unit before you delete it.

You cannot delete the default business unit team but it won’t stop you deleting the business unit because this will be deleting automatically when you delete the business unit.

Like all things in CRM, Microsoft recommend you disable business units rather than delete them, the reason being disable business units just like disabled records can be re-enabled but once something is deleted it’s gone forever.

 

Security Roles

Security roles are a vital part of the security in CRM because if a user doesn’t have a security role he cannot access the system, so every user must have at least one security role.

Security roles are linked with the user business unit to calculate what records the user can access.

Users receive their permissions to work on records or use features based on the combination of Security Roles they are assigned and the Business Units to which the users belong.

Security roles can also be assigned to teams and if the team a user is a member of has higher security privileges then this will override their individual security roles.  The user will also use the highest security levels it is assigned, whether that’s from a security roles assigned to the team or individual security role

Users can be assigned multiple security roles, this means it’s possible to create security roles just for single purposes.

 

Default security roles

There are 15 default security roles in CRM, this provide a good basis to start creating your security roles.  The default security roles are all created in the root business unit.

You need to understand how security roles work with business unit, they can be a bit cheeky.  A security role stays in the business unit it is created in and they copy down to any child business units.

The above line is import because if you create a security role in the root business unit then the security role will be copied to all the child business units below it.

So you should be careful about creating security roles not in the root business unit because this means you will have a security role that doesn’t exist in any parent business units and in particular the default business unit.  Another consideration is only security roles which exist in the root business unit can be added to a solution file.

What I am saying is don’t create security roles not in the root business unit because you cannot export these out and it may cause a bit of headache if you need the parent business units to use the same security role.

User can be assigned any security role which exist in their business unit.

 

Modify, Don’t create security roles

When you set up a new security role there are hundreds of settings you need to setup, there are 8 privileges for each entity.  The quickest and easiest way to do this is to copy an existing role and modify it.

Microsoft recommend you don’t delete the default security roles so you can have them as a reference but once you have a few security roles I personally don’t think it matters but remember the MB2-703 certification is written by Microsoft and they want the answers they are expecting.

 

System Administrator Role is all powerful

All security roles are the same except the System Administrator role which is a super role.

The System Administrator role automatically has access to all records and entities, including all custom entities.  It has the default access level of organisation for all privileges.

One user must have the System Administrator role, this is by default given to the user who installed CRM.  Multiple users can be assigned the System Administrator role and you can remove the role from users but you cannot remove the role if that user is the only user who has the System Administrator role.

The System Administrator role also is given the System Admin field level security role, which as I’m sure you can guess gives them access to all field level security.

It’s possible to copy the System Administrator role and it will create a security role but the security role will not automatically have access to any new custom entities added and it basically won’t have the special powers of the System Administrator role.

 

Security roles Privileges and access levels

At this point I am going to refer you to the excellent blog on security roles written by CRM MVP Richard Knudson, this blog post has 40 comments, which shows you how many people have read it.

I would also say that this part of the CRM security can be tricky to understand but with regards to the exam does not have as many gotcha’s.

http://www.dynamicscrmtrickbag.com/2011/07/20/dynamics-crm-2011-security-roles/

This blog post about understanding access levels and roles is also very useful

http://www.dummies.com/how-to/content/understanding-access-levels-and-roles-in-microsoft.html

There are some privileges which do not have organisation levels these are always show under miscellaneous privileges and these are either true or false.  These are things like

Go Offline

Export to Excel

Publish articles

 

This is a good place to leave security with more to come

I published the video before the blog article and very kindly Adam Vero (CRM MVP and an expert on CRM as he wrote some of the MOC’s on the subject) left me a couple of excellent comments where I got slightly mixed up in the video.

 

Adam Vero

When you disable a Business Unit, it disables the BUs below it, that is correct. But it does NOT disable the users in the BU or any of the children. They are prevented from logging on while they are in a disabled BU, but when you re-enable the BU they can. (If it disabled them all then when you re-enabled the BU it would have no way to know which users to re-enable if some were already disabled manually previously).

Reply

 ·

Hosk’s Microsoft Dynamic CRM Development

good point, I think you have basically said what I was thinking and meant to say.  I guess it can seem like the users are disabled because they can’t login but you are right because they aren’t disabled but stopped from being able to login.

Great Comment thanks CRM Master.

Adam Vero

Notice that when you change the parent business unit of a BU, this is not just changing the position in the hierarchy and therefore changing the impact of the access levels that people have to records in that BU. It will also REMOVE all inherited Security Roles (and rebuild them) – it does not move the roles with it. So at the moment you move it, the users in that BU have no roles other than any that exist directly in that BU (which often is zero, if everything is always created in the root or imported via Solutions). In most cases this means those users just stopped being able to log on, and you’d better remember who had which roles originally. Users may be able to log on if they are a member of a team that has a suitable role, and they have logged on at least once before, but this is an edge case – expect problems with logons when you move a BU.

Hosk’s Microsoft Dynamic CRM Development

so changing the parent business unit of a BU can remove all the security roles from the users in that business unit.  I guess this makes sense because it (as you say) has to rebuild the security roles because you are potentially removing all the inherited roles it had.

This is a good point to consider for the CRM exam.  I will include this in my Security role exam cram notes and maybe make a test question on it.

Thanks again Adam, excellent comment.