Securing data inside Dynamics 365 is critical and its something that should be imbedded from day 1 of your use of the D365 Apps. This blog post covers the Microsoft Dynamics 365 application family – but is not targeted at the D365FO family of products.
How is the Security Model applied?
Dynamics 365 is built upon the Azure Active Directory and is integrated with the Microsoft 365 account system (this used to be called Office365). (Tip: You can get an on-premise version and in that case you will need a local active directory account)
What is the Purpose of a Security Model?
Essentially all applications have some form of security requirements, and D365 is no different: In Dynamics 365 the security model is aimed to:
- Control access to data records and sometimes specific fields/data values
- Control access to application functionality
- From a security perspective
- from a User Experience Perspective
What are Security Roles?
Security capabilities in Dynamics 365 are not assigned directly to the user per se, Instead Security Roles are created and they are made up of specific Privileges and Access Levels. Its the role that is then assigned to a User or Group of users (a team).
Security Roles are made up of a combination of:
- Write – change data
- Append – link records of this entity to other entities
- Append to – link other entity records to this entity
- Assign – change the owner of the record
- Access levels
- None – you cannot see or change any records in that entity.
- User – Can use my own records and records shared with me
- Business Unit – everything you had from the user level + records created by or shared with other people in the same business unit as me
- Parent/Child (if more than 1 Business Unit exists) – plus any records created in lower business units in the hierarchy
- Organisation (if more than 1 Business Unit exists) – you can see everything.
Once a security role exists, it can then be assigned/linked to a User or Group of Users (Teams), who inherit those Privileges and Access Levels.
You can see the data entities listed down the left hand side, and you can see the D365 apps listed across the page as tabs.
Tip: We recommend not amending existing Microsoft provided security roles but instead copy the standard role and edit that instead. Remember if you do this when Microsoft update the application you may need to go back to these copied roles and add-in new functionalities that have been added since you copied the role!
The above is based around record level security (row in the data entity), if you want to manage security at field level this is possible but adds an overhead to maintenance and setup
Business Units in D365
In Dynamics 365 security boundaries are set through the use of Business Units through Access levels mentioned above. If you are a small company you might only need 1 x business unit, but as you scale you may need to create multiple business units e.g. you might want a business unit for a specific department (unlikely to need a business unit per department though – don’t make it hard work to manage!)
A Security Role belongs to a business unit and it can made available in multiple Business Units at a time. In fact if you link a Security Role with a parent business unit, then that role is automatically available through inheritance, in all child business units of that parent.
A user can only be allocated Security roles that have been associated with the business unit they have been setup in.
A User in D365 can only be a member of 1 business unit at a time. You are able to move a user between units, but it can only be a member of 1 at a time.
Tip: For simplicity we recommend you only create Security Roles in the root Business Unit, then you know they are available in every business unit. Also this prevents the issue you will see for 2 security roles having the same name, when a role created at the root is given the same name as a role previously created at a lower level in the business unit structure.
What happens when you move a User between Business Units?
This can cause real problems, because although the records they created will still be owned by them, other users in the old BU may no longer be able to access those records.
Using Microsoft 365 Teams (not the MS Teams app)
A user can be part of a single team, or multiple teams. You can assign specific user roles to a team. The user will inherit the most non-restrictive rules based on the group memberships – so imagine that an ‘allow’ will override a ‘deny’ situation. Teams are managed within Microsoft 365 (ex-Office365) and not Dynamics 365.
Many organisations only manage security for Dynamics 365 at the ‘teams’ level. This makes management a lot easier but not so flexible. This is our recommended starting point in security design for D365 though.
Manager Hierarchy & Position Hierarchy
The concept of this extension to securoty model above is that it allows us to give users permissions to see records created by their staff. This is facilitated either through the use of the ‘manager’ record on their user record, or through the use of the position hiracrhy based ont he setup of positions in D365.
This is not enabled by default – something you need to turn on in D365.