As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look a little deeper into the Dynamics 365 security model.
I have already given an overview of security, when I explained the concepts behind business units, users and 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! But security does more than just manage data access, the interface is often enhanced for users by restricting access to entities they don’t use. By offering less options and therefore creating a cleaner UI.
Business units provide the foundation for the security model, roles are then defined that sit within the business units. Each user or owner team will be assigned a business unit and one or more roles. This combination of entities provides the basis for the Microsoft Dynamics 365 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 organization. (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 parts 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 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.
For example, below we can see that in the business management tab of a security role we can control many options relating to privacy and many more miscellaneous options. Privacy options doing things like restrict users from being able to export data to excel. In miscellaneous we have many diverse options including restricting using from using the bulk edit feature or merging records.
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 Dynamics 365.
Tip:
Roles can be assigned to owner teams or users. When a user is part of an owner team they inherit the permissions granted by the role on the team. Consider this, as adding a user to a team effectively gives them a role.
Security Roles
Security roles define the privileges which will be granted to users or owner 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, they 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 organization 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 Dynamics until a new role is assigned. Meaning they can also not log into Dynamics 365 until a new role is assigned.
A set of default roles ship with Dynamics 365. 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. (A detailed definition of these options is given below.)
NOTE:
Entities which can be user owned support all of these variations but organization owned entities will either be a red circle or sold green dot. Simply as the other options don’t apply to them. (You either have access to an organization owned entity or you don’t!)
Teams & Security Roles
Some things to note about teams and security roles include;
- Roles can be assigned to owner teams. (Roles can’t be assigned to access teams.)
- A security role MUST be assigned to an owner 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 organization. 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. You will find the Positions option in Security area of settings in Dynamics 365.
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.
As always please experiment with all of these options as port of your preparation. Hands-on usage of the system is by far your best preparation! Do not rely on theory alone.
Hopefully this post will have been useful for anyone preparing for the MB2-716 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…..
NEIL PARKHURST 
Leave a comment