As I prepare for my Dynamics 365 certification in sales (MB 210), I’m creating blog posts based on my revision. I hope that collectively these posts may prove useful to anyone also preparing for the MB 210 exam. This time I will cover the concepts around sales security roles.

You will see that security roles are mentioned in the skills measured statement within the section headed “Perform Configuration”.

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

There are several “main” security roles you might want to review. Including, Sales Manager, Account Manager and Sales Person. Plus maybe lots of other related roles such as marketing manager.

For example, you may find that a sales manager can delete any account in their business unit and any child business units. And that an account manager can only delete accounts they own.

At this point, depending on your knowledge of the Dynamics 365 security model the above statement will either make complete sense or present some now concepts! As you’ll need to appreciate what actions we can control, such as delete. And what a business unit is and how they relate to each other.

And of course, we possibly 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 hieratical 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 sales related security roles are implemented.

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 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.

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 organizational 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;

Some points about business units you might need to know;

1. The root business can be renamed.
2. The root business unit cannot be deleted or disabled.
3. The root business unit cannot be moved to have a parent business unit.
4. The name of the root business unit will default to the organization name when the system is first deployed.
5. 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.
6. The parent business unit on a new business unit will always default to the root but can be changed.
7. 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.
8. Child business units can be renamed.
9. Child business units can be disabled.
10. Child business units can be deleted but only after being disabled.
11. Any users in a business unit will lose access to the application if the business unit they are assigned to is disabled.
12. 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! However, you may find 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. With Dynamics 365 online 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 lot 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 they can log into Dynamics 365 again.

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 for each entity / feature in Dynamics 365.

Entities typically have multiple access options covering functions including, create, read, write, delete, append, append to, assign and share.

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!)

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 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.

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 / 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.)

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 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.

Hopefully this post has given you a good introduction into the Dynamics 365 security model. If you’d like to dive deeper into the detail the post below will hopefully provide some extra facts!

https://neilparkhurst.com/2017/05/11/mb2-716-microsoft-dynamics-customization-and-configuration-security-model-detail/

As always, I encourage you to experiment with security roles hands-on. As part of your MB 210 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.