MB-200: Microsoft Dynamics 365 Customer Engagement Core – Security

I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around Dynamics 365 security.

You can see below that security roles, users, teams and hierarchy security are mentioned in the implement security section of the exam.

To understand security roles you will need to appreciate several related concepts including business units, users and teams. So I will cover all of these in this post!

Security roles govern what actions a user can complete on a record. You’ll need to appreciate what actions we can control, such as create, delete, assign and share. Plus you’ll need to know what a business unit is and how the units can relate to each other.

Additionally we have multiple approaches to security. For example, access to each record is generally based on an ownership model. For example, I can only read (see) accounts I own. But other options such as hierarchal security exist. Something that maybe useful when you want to grant a sales manager permission to see amend all of the record owned by her team.

Other security requirements might include requirements to restrict access to a single fields or maybe we need to grant access to specific records. (Known as access teams.)

Therefore, I will devote the rest of this post to attempting to give you an overview of the security model. Armed with that knowledge I encourage you to then spend time reviewing how the out of the box security roles are implemented.

Tip: As part of your revision the best way to understand security roles might be to open up some of the out of the box roles and review what actions each would enable.

The options / entities related to security are as follows;

Users, allows you to manage users and associate them with business units / teams and roles.
Teams, this option lets you define teams and also associate with security roles.
Security Roles,
security roles let you define what access will be provided to teams and users. Roles are created and then one or more are associated with each user / team.
Business Units are a fundamental building block in the Dynamics security model. They define the structure of the organization.
Field Security
Profiles are used when you need to define specific access rights on individual fields.
Hierarchical Security supports a security model based on someone’s hierarchy. Which can either relate to the manager they have defined in their user or positions.
Positions define organizational positions which support the hierarchy security model.
Access Team Templates support dynamic record sharing. With the members of an access team being given privileges on specific records based on the access team template.

Business Units

The first construct to consider are business units, these allow you to define the structure of your organization. Users, teams and security roles will be linked to business units making them a fundamental building block in the security model.

Below you can see that I have created an example business unit. All of my international sales team will be linked to this business unit. Notice that most of the fields about address (etc) have been left blank. These extra fields are not essential but might be really useful for reference purposes. (However they have no functional use within the security model!)

Business units can have a hierarchy. This might reflect the organizations actual hierarchy but that isn’t always the case. In actual fact the hierarchy is designed to “drive” which users get access to what records. I have created a very simple organizational structure below. With sales and service being split. Plus, sales being further split into UK and US teams.

In Dynamics 365 the above business unit hierarchy looked like this;

Some points about business units you might need to know;

The root business can be renamed.
The root business unit cannot be deleted or disabled.
The root business unit cannot be moved to have a parent business unit.
The name of the root business unit will default to the organization name when the system is first deployed. (But you can change it.)
All child business units have a parent which will either be another child or the root business unit. Meaning the root business unit is always the top of the business unit hierarchy.
The parent business unit on a new business unit will always default to the root but can be changed.
The definition of business units often follows the companies organizational structure but this is not essential. Ideally the business unit structure should mirror whatever is needed to support the security requirements of the organization.
Child business units can be renamed.
Child business units can be disabled.
Child business units can be deleted but only after being disabled.
Any users in a business unit will lose access to the application if the business unit they are assigned to is disabled.
Child business units can be moved under a new parent – If you move the business unit users will move with the business unit.

Tip: The root business unit can be renamed! But historically I have found that the parent business unit field is mandatory. Which makes it impossible to save the change of name. (As the root does not and cannot have a parent business unit.) To resolve this you need to remove business required status on the parent business unit!

Users

Firstly, users will need to be created. This means they must exist as a user within Office 365. Additionally, they must be assigned a Dynamics 365 license.

Once the user signs into Dynamics 365 the security model is used to control what they can access. This is achieved using the manage roles option on the user.

Tip:
As you will soon see the combination of the user’s business unit and security role(s) will govern what access they have.

When creating users, the business unit is a mandatory field and will default to the root business unit. To access Dynamics 365 a user must also be given at least one security role. (Or be assigned to a team that has a security role!)

If you need to change a user’s business unit use the “change business unit” option. If the user owns a large volume of record in Dynamics 365 this process can take a long time! If you move a user from one business unit to another their security roles will be removed. Meaning, having completed a change of business unit, new security roles will need to be added before the user can log into Dynamics 365 again.

Security Roles

Each role is linked to a business unit. The roles then contain many options that govern the access to entities / features for the combination of business unit and user.

Often roles will be inherited from a parent business unit. Meaning when I use the manage roles on a user linked to a child business unit, I still see the roles from the parent business unit. This happens even though I haven’t created any roles specific for the child unit!

Each user can have multiple roles. The Dynamics 365 security model works on a least restrictive security model. Meaning a “sum” of all the roles assigned to the user would be applied.

Each role is made up of several options (actions) for each entity / feature in Dynamics 365. Entities typically have multiple actions covering functions including, create, read, write, delete, append, append to, assign and share.

Each entity can have eight different types of action. (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 – gives the ability to change the owner of the record, to another team or user.
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.

The options govern the level of access. (As shown in the key below.) Not selected means the user will not have any access. User access would signify they can only work with records they own. We then have an increasing level of access that gives a greater and greater amount access based on the business unit hierarchy.

Tip:
When we create entities in Dynamics 365 they can be user / team owned or organization wide entities. Organization wide entities only have two access options. (None and organization!)

A detailed definition of these options is given below…

Teams

Teams have several uses in Dynamics 365. Teams are essentially listing or groups of users and can be used to help manage security. Teams may also be useful when creating reports. Additionally, teams can be useful when you wish to share “assets” with a group of users. (Assets could include views, charts, dashboards or records.)

You will find the option to maintain teams in the security area of Dynamics 365 advanced settings.

Business Units and Teams

Each business has a default team. This is a “special” team that cannot be removed. Users are automatically added as they are assigned to the business unit. Below you can see the default team for my International Sales Department. Notice the description highlights the fact that this is a default team.

Team Types

Owner teams are the original / traditional type of team found in Dynamics 365. Owner teams have members and the team can own records. (Assuming they have a security role that grants sufficient permission!) For example, an account might be owned by the “International Sales Team” rather than by an individual user.

Access teams are a special type of team giving record sharing capabilities.

It is important to understand that owner teams can have a security role. Members of the team will inherit the permissions granted by the team’s security role(s). Should you wish records to be owned by the team it must have a role which grants access to whatever entity is to be owned.

Owner Teams

The membership to owner teams can change but tends to be static. Someone joins the team and remains part of that team for all “activities” conducted by the team. An owner team has a finite number of members at any point in time.

Owner teams are useful when reporting on the team as a whole is required. For example, the team could have a goal and be measured as a group against that target.

Owner teams are associated with a business unit. As they will need to be assigned a security role from that business unit. But the members of the team do not have to belong to the same business unit. This is useful when a group of people need to collaborate across business units.

Note:
Also notice that the team has a default queue. (As does a user!) You should probably make yourself aware of them! Queues are a useful construct for managing lists of outstanding work items. You could for example create a queue containing service cases that need attention. And give everyone in the service team access to that queue.

Access Teams – User-Created

User created access teams are used to easily share records with a group of users. They are in many ways very similar to owner teams! As they have members in a very similar way.

Except, user-created access teams do not have roles and cannot own records. Although records can be shared with them without the need to the team owning the record.

Below you can see that I have shared an account record with the access team I created above. And that the team members have been granted read access on the account.

Access Teams – Auto-Created

Auto-Created Access teams are used to share individual records. These access teams do not own records and cannot have roles. They are by implication very fluid / dynamic teams and will be formed or dissolved almost at will.

The number of members, who those members are or even if the team will exist is not a given. Consider an access team used on opportunity to reflect the sales team. It might be the opportunity is very small and an access team is never required for that sale. Or it might be a large potential that needs multiple people involved.

On my opportunity form I’ve added a sub grid in which I list the access team members for the opportunity. Any users added will be part of the access team for that specific opportunity. Giving them all rights to maintain that opportunity. (Based on an access team template.)

Before you can use an access teams on an entity it must be enabled for access teams. To do this you will need to use the customizations option. And under Communication & Collaboration enable the entity for access teams.

Once enabled you CAN disable access teams if required.

Having enabled the entity for access teams you will need to create an access team template. Access team templates are defined in security settings in Dynamics 365.

Below you can see an example of an access team template for the opportunity entity. This is used to grant members of the access team privileges on individual opportunities.

Note: You are limited to 2 team templates per entity.

A sub grid for the team members will need to be added to the entity. Below I have shown the access team I added to my opportunity form. (Again using the Dynamics 365 customizations options.) Notice that in the data source the records field is set to All Record Types, I have then selected Users as the entity. And I have set the default view to Associated Record Team Members. Then finally I have selected the required access team template opportunity.

If the access team template is changed, the revised permissions will not affect any existing access teams. Only as new records are created will the revised permissions take effect.

If an access team member has the share privileges. When they share the record their access team privileges will be shared. Meaning if someone has share ability but cannot delete a record. The people they share the record with will also not be able to delete it.

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, hierarchy based on reporting lines or positions. You will find the hierarchy and positions options in the advanced settings area.

Hierarchy security leverages settings on the system user entity in Dynamics 365. Each user can have a manager defined. It might be that the manager needs to have access to all the records of their team.

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 the 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 any 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 system user records) or based on custom positions. 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.

Hopefully this post has given you a good introduction into the Dynamics 365 security model.

As always, I encourage you to experiment with security roles hands-on. As part of your MB 200 revision I suggest you try creating multiple users and grant them different permissions. Then login as each user to see how this effects what records they can access and what functions they can perform on those records.