MB2-716 (Microsoft Dynamics 365 Customization and Configuration) – Security Overview

This is the next post in a series covering my revision for the MB2-716 certification. (Microsoft Dynamics 365 Customization and Configuration) In this post I will introduce the Dynamics 365 security model. Including an overview of business units, users and teams.

If you are an experience Dynamics 365 user, hopefully the concepts here are very common to you. But a quick bit of revision never hurt anyone! 

The security area of settings in Microsoft Dynamics 365 gives you access to most of the options needed to manage users, roles, field security etc. Use these options to configure how users interact with Dynamics 365 and allow or deny them access to data.

The options are as follows;

Users, allows you to manage users and associate them with business units / teams / roles and assign licenses.
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.
Hierarchy 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 option to consider is business units, this allows 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. (I wish!) Notice that most of the fields about address (etc) have been left blank. These extra fields are not essential and are really just for reference in the application, meaning they have no function with the security model.

Some points about business units you will 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.
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 organisational structure but this is not essential. Ideally the business unit structure should mirror whatever is needed to support the security requirements of an organisation.
Child business units can be renamed.
Child business units can be disabled.
Child business units can be delete 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: In past exams I have often seen questions around what can and can’t be done with root and child business units. Make sure you know this stuff!

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 uses heavily in the security model to drive which users get access to what records. I have created a very simple organisational structure below. With sales and service being split. Plus service being further split into UK and US teams.

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

Users

Firstly users will need to be created an authenticated. In an on premise architecture this will mean the user must exist within Active Directory and with online they must exist as a user with Office 365.

Note: If you sync your local active directory with your Azure active directory, it is possible to sign into CRM online using a local AD account.

Once the user is signed in, either via Office 365 or AD, then the Dynamics 365 security model is used to control what they can access.

When creating a user in CRM (on premise) we use the “Users” option found in the security area. The user name is the domain name and user name from active directory.

With Office365 the process is a little different. As you will need to assign a Dynamics 365 license in the Office 365 admin area. Below you can see that I have created a user called “Jasper Cat” and assigned a Dynamics license in Office 365. Following this process in Office 365 will create the user record in Dynamics 365 but I will then need to use manage roles in Dynamics before Jasper would be granted access.

Tip:
Notice that I have also assigned an Office 365 Enterprise E5 license. You may find you also need to assign additional licenses to grant access to any integrated extensions. (Such as OneDrive, Office 365 Groups etc.)

Note:
With online, when we create a user and assign a license in Office 365 the user is created in Dynamics 365. However at this point the user cannot login into Dynamcis 365 as they must also have a role assigned. The exception to this is when a license is assigned to a Global Admin in Office 365. As they will be automatically given System Administration access in Dynamics 365.

When creating users, the business unit is a mandatory field and will default to the root business unit. To access CRM a user must also be given at least one security role.

With online … You should also keep in mind that some information such as job title and phone numbers will be read only, as these fields are maintained directly in Office 365 admin not Dynamics 365.

With on premise an option exists to add multiple users. Having selected the option “NEW MULTIPLE USERS” you will be prompted for a business unit and the role(s) to assign. As all the new users will need to be added to the same business unit and have the same roles. You will then be asked to confirm some details such a license type.

Finally, you can select the users you wish to add from Active Directory. This approach is very useful when adding a large number of new users, you just need to keep in mind that all the users created will have the same business unit and role(s). So you may need to run the option multiple times if a structure of business units exists.

You cannot delete users. You can however disable them. With on premise you can simply disable the user within the Users area of CRM. With online you need to open the user in Office 365 admin and remove their license.

If you change a user’s business unit that can be done with the change business unit option. If the user owns a lot of record in CRM this process can take a long time! If you move a user from one business unit to another their security roles will be removed. So having completed the move new security roles will need to be added before they can access CRM again.

Roles

I will discuss more detail on how to create roles and how they operate in a future post. At this point it will enough to understand that each user can have one or more roles. And that you use the MANAGER ROLES option on the user’s record in Dynamics 365 to do this.

As I have said I will cover roles in greater detail later. But one concept worth mentioning here is that some roles will be inherited from the parent business unit. So even though I haven’t created any roles specific to the International Sales Department I still see all of the out of the box roles defined on its parent. (In this case the root business unit.)

Teams

Teams have several uses in Dynamics 365. Teams are essentially lists 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 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 “CRM”. Owner teams have members and the team can own records. (Assuming granted permissions to do so with a security role!) 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.

I will cover security roles in more detail in a future post but 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). Also, should you wish records to be owned by the team it will require 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!) Queues are explicitly mentioned in the skills measured for the MB2-716 exam, so I won’t expand on them here. But you should probably still 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 / dynamics 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 deal is very small and an access team is never required for that opportunity. Or it might be a large deal that needs multiple people from sales 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.)

NOTE: When users are added to the sub grid in background an access team for this specific record is automatically created. By default you aren’t going to see this team in the security settings area of CRM. But you can do an advanced find on teams to view it if required.

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 in CRM. 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 record 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.

I hope this post will have helped you revision for MB2-716. We have covered quite a bit! In trying to explain the basics of the Dynamics security model we have reviewed business units, user management, owner teams and access teams. As always experiment with these concepts hands-on. Next time I will dive deeper into the security model looking at security roles in more detail and other concepts such as hierarchical security.