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
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:
|
| 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:
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.
Great Comment thanks CRM Master.
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.
Hosk's Dynamic Blog 