Here I will continue my series of posts aimed at helping anyone preparing for the MB2-712 certification. (Customization and Configuration in Microsoft Dynamics CRM 2016)
I have already given an overview of security and gone into detail regarding teams, in this post I will build on this information giving more details about the security model, including roles and hierarchy security.
Introduction
Security is a very significant part of configuring your Dynamics system, as ensuring the users can see the information they need is essential. And possibly even more fundamental is restricting access to sensitive information when required. But security does more than just manage data access, the user interface is often enhanced for users by restricting access to entities they don’t use. As by doing so they will disappear from the user interface giving the user less options and a cleaner UI.
As already mentioned business units provide the foundation for the security model, roles are then defined that sit within the business units. Each user or team will be assigned a business unit and one or more roles. This combination of entities provides the basis for the Microsoft Dynamics CRM security model.
However, beyond this “basic” structure of roles we have other options such as Access Teams, Hierarchy security, field security and role based forms. I have already described how access teams can be used to control access in a fluid manner to individual records. Later in this post I will describe how hierarchy security can grant permissions based on someone’s position in the organisation. (A sales manager for example, might be given access to all the opportunities created by his sales team.)
Security Model
The security model does more than provide access to a record, as you can control what actions a user can take. Including creating new record, updating existing ones, deleting data, sharing and even if we can append (or append to) data.
The security model is also used to control access to part of the user interface, including forms (role based forms), fields (field security), dashboards and business process flows. (Dashboards and business process flows can be enabled for all or nominated security roles.)
It is also possible to define allow or deny access to various features of the software. Such as bulk edit, merge, sync to outlook, export to excel, print etc etc. I have, for example, worked in a company that wanted to protect its lead data. So the field sales team could not export data to Excel but this capability was given to sales managers.
It should be noted that the security model will apply to all system AND custom entities. Plus, as already mentioned, all users must be assigned at least one role. If they aren’t they will not be able to access CRM.
Security Roles
Security roles define the privileges which will be granted to users or teams. Each can have more than one role, with the security model working on a heritance model. Meaning the user will get the sum of the privileges granted in all the roles.
Roles are created at a business unit level. If a role exists on a parent business unit all of its child business units inherit that role. It is quite common to keep security roles simple be defining one set of roles that exist on the root business unit, there then take effect in all business units. But when you need a more granular approach to grant “special” access to a specific group within the organisation this structure will allow it. Below I have shown that if you open an inherited role you cannot change it, as any alterations must be done in the parent business unit.
Note, you can copy the out of the box roles to create a new one if changes are required.
User can be added to roles by using the MANAGE ROLES option from the user record.
Note:
When changing the business unit of a user the associated security roles are removed. The user will not have access to CRM until a new role is assigned.
A set of default roles ship with Dynamics CRM 2016. You can use these out of the box, alter them as required or copy them to create your own roles. Personally I like to leave the out the box roles unchanged, I then copy them as required. Effectively using them as a template for my bespoke security model.
Out of the box roles include sales manager, salesperson, marketing manager, scheduler etc.
When we look at a role we can see LOADS of privileges that can be set. These are grouped into tabs that follow the functional areas of CRM, such as marketing, sales etc. We also have a tab called “Core Records”, here you will find the most significant entities that are common to all areas of CRM.
We also have a tab called “Custom Entities”, this is where all of your custom entities will be shown. Some of these will be created by you as a developer but others may relate to third party solutions you have imported.
Each entity can have eight different types of privilege. (Some are obvious in terms of what they do, some might need a little more thought!)
- Create
- Read
- Write
- Delete
- Append, attach this entity to other entities. (Notes for example would need append enabled.)
- Append To, attach other records to this entity. (Account for example would need “append to” so Notes can be added.)
- Assign, assign gives the ability to change the owner of the record, to another team or user.
- Share, share allows someone to share the record out with other users. (This does not change the owner!)
Note:
When you share a record you cannot / do not give any more access than you currently have.
Under each of these headings you will see a circle. This defines the scope of the access level being granted. A red circle means no access; a solid green circle means total organization level access. In-between we have several options which grant access to just records owned by the user, records within their business unit or records in their business unit and its children.
NOTE:
Entities which can be user owned support all of these variations but organization own entities will either be a red circle or sold green dot. (Simple as the other options don’t apply to them.)
The Business Management tab in a role gives control over several system wide entities. Such as business units, goals and users. Also on this tab you will find the ability to grant access to numerous features within the application. Such as bulk edit, access to CRM mobile applications or sending an email on behalf of another user.
Teams & Security Roles
Some things to note about teams and security roles include;
- Roles can be assigned to teams.
- A security role MUST be assigned to a team for it to own records.
- A team always links to one business unit.
- Team members can belong to any business unit.
- Heritance of security permissions works across users and teams. Meaning the privileges from roles assigned to the user are combined with roles assigned to teams the user is a member of. (Granting them the least restrictive access level.)
- It is possible to have two security roles with the same name. Each role could be linked to a different business unit and could give users in each business unit differing levels of access. You need to be aware of this as it could appear confusing!
- Just like with users, if you change the business unit on a team the security roles associated with the team are removed.
Tip:
On teams (or users) you can select multiple teams in the list view of teams. Then the MANAGE ROLES option can be used to add roles to multiple records at the same time. You should however be aware that it is not possible to remove teams (or users) from roles in this manner.
Hierarchy Security
The standard security model will fit most situations but we have a further option that might occasionally provide benefit. The concept of hierarchy security is to grant permissions based on someone’s “hierarchal position” in the organisation. This could be defined in one of two ways, the first uses settings on the system user entity in CRM. Each user can have a manager defined. It might be that the manager needs to have access to all the records of their reports. Another concept would be to define positions. Users can then be assigned to those permissions. It might be that anyone who is classed as having the position of “Board Member” would have read access to any data for people in positions “below” them.
Note: It should be understood that hierarchy security is not designed to replace that standard approach. It is supposed to be used in conjunction with the existing security model to give greater flexibility.
The hierarchy structure can span the business units again helping to provide an additional dimension to the security model.
A further concept is depth. If your hierarchy has many levels, you can define how many layers to go down in the structure. It might be that the National Sales Manager can read and edit any opportunities for his direct reports. But if one of those reports is an area manager, then the National Sales Manager can still read records for the direct reports of the Area Manager. (But can’t change them.)
Note:
To be clear, with non-direct reports the manager would only have read access. For direct reports that manager will have read, write, update, append and append to access. Also for the manager to have access to the records for direct or non-direct reports they must have at least read privilege on the required entity.
These concepts can create a very granular approach. Let’s look at them in more detail.
When you first set-up hierarchy security it must be enabled. This is done in the Hierarchy Security option found in the security area of settings.
Once enabled you opt to use this approach based on the manager hierarchy (as defined on the CRM users) or based on custom position hierarchy. I will describe how to create a custom hierarchy in a second! You must use one or the other approach a mixture is not possible.
Next you define how deep the hierarchy should go. A manager will have Create, Read, Update and Delete access to their direct reports. But then this depth option is used to decide how many layers below that they can see. (Note: See as they only have read access as they go deeper in the hierarchy.)
Finally, we select which entities this should apply to. By default, the hierarchy security model applies to all entities. But you can opt to exclude entities. In the example below I have elected to exclude everything except Account, Contact and Opportunity.
To define a custom position hierarchy, you use the positions option that can be found in the security area of CRM under settings. Below you can see I have created a hierarchy of positions as a simple example of how they might be defined.
When I open one of the positions you can see that users who have that position can be listed.
Hopefully this post will have been useful for anyone preparing for the MB2-712 certification. You may have noticed that I didn’t describe field security, role based forms or enabling roles on business processes & dashboards! This is simply because I haven’t covered how to create and customize entities, I will explain additional security options when I do that. For now, it is hopefully enough to know these options exist. J
NEIL PARKHURST 
Leave a comment