Dataverse has been developed for Dynamics where comprehensive data security is essential. For this reason, Dataverse security is incredibly powerful and flexible, but with that comes a level of complexity!
In this post I’ve tried to simplify and explain the key Dataverse security concepts and how they hang together
Dataverse Security
At its core, Dataverse uses Security Roles to group together a collection of privileges and allocate them to Users, Teams or Business Units. Privileges are simply entitlements to create, read, update or delete records
Users belong to a Business Unit and can be part of one or more Teams. As well as being able to have Security Roles assigned directly to them, Users also inherit the Security Role privileges from their Business Unit and from any Teams they belong to
The privileges granted to users are cumulative with the greatest level of access prevailing
Business Units, Users, Teams and Security Roles are Dataverse tables. Every time new records are created they are added to these tables
The tables have relationships to each other, just as all other tables in Dataverse
Below is the Dataverse schema that forms the core of the Dataverse security model
Dataverse Security Model
The Organisation is the top level of the Microsoft Dynamics 365 business hierarchy. An Organisation must have at least one Business Unit
The creation of Teams is optional
Business Units
- Every Dataverse database has a single root Business Unit which is owned by the Organisation. If no other Business Units are created then all Users belong to the root Business Unit
- Additional child Business Units can be created that have the root Business Unit as their parent
- Further Business Units (grandchildren, great grandchildren, etc) of child Business Units can also be created
Users
- Users are always initially assigned to the root Business Unit but can be re-assigned to any other Business Unit at any time
- Users can also have owning Users (managers). A manager can manage multiple Users and there can be multiple tiers of management
Security Roles
- Security Roles can be assigned directly to Users, Business Units or Teams
- Security Roles have a many to many relationship to Users so that a Security Role can have many Users and a User can have many Security Roles
- Security Roles also have a many to many relationship with Business Units and Teams
- Users who belong to a Business Unit receive the cumulative privileges offered by all the Security Roles assigned to the Business Unit, in addition to any Security Roles assigned to them as a User
Teams
- Teams are owned by a single Business Unit and a Business Unit can have multiple Teams. Teams cannot belong to other Teams
- Teams have a many to many relationship to Users so that a Team can have many Users and a User can belong to many Teams
- Teams also have a many to many relationship with Security Role
- Each business unit has a default Team to which all Users in a Business Unit are automatically added
- You cannot delete the default Team or add/remove Users from it. However you can change a User’s Business Unit and the User will automatically be removed from the existing default Team and added to their new Business Unit’s default Team.
- You can assign Security Roles to the Business Unit’s default Team. This can be done to simplify Security Role management so all your Business Unit team members can share the same data access
- Users from any Business Unit can be assigned to a Team
- If a Team is given one or more Security Roles, then Users who are assigned to the Team inherit the cumulative privileges of those Security Roles in addition to any Security Roles assigned to them as a User or assigned to the User’s Business Unit
As well as the Owner Team described above, there are also Access Teams. An Access team is different to an Owner team because it can’t own records and can’t have Security Roles assigned. Owner team members create records based on the privileges defined by their user assigned Security Roles, their Business Unit and from the Owner teams they’re members of. These members can then share records with an Access team so the team has access rights to those records
Azure AD Security Roles
Security Groups are used to manage access to environments and are extremely useful in helping to simplify Security Role allocation
Security Groups can have one or more Security Roles assigned to them. Users can then be assigned to Security Groups. This means the complexity of the many-to-many relationship between Security Roles and Users is simplified because new Users don’t need to be given multiple Security Roles, they are just added to the appropriate Security Group
Record Ownership & Security
Now we’ve covered the essentials of Dataverse security, let’s delve into a little more granular detail
Table & Record Ownership
Dataverse supports two types of record ownership. Organization owned, and User/Team owned. This is a choice that is made at the time the table is created and can’t be changed
For organization owned tables, if a User is given access to a table they gain access to all the records
For User and Team owned records, a User can be provided or denied access to a particular record depending on the record’s ownership
Record-Level Security
Record-level access defines whether a User has access to individual records in a table. For example, Users could be restricted to only being able to access records they have created
For a given User, the records they have access to is defined by the combination of all their Security Roles, the Business Unit they are associated with, all the Teams they are members of and the records that are shared with them
Column-Level Security
Record-level control of access is not adequate for some business scenarios. Dataverse also has a column-level security feature to allow more granular control of security at the column level. For example, salary data could be hidden from non-approved Users
Column-level security can be enabled on all custom columns and most system columns. Most system columns that include personal identifiable information (PII) are capable of being individually secured
Summary
As I mentioned in the introduction, Dataverse security is a complex subject. There is oodles of comprehensive Microsoft documentation available. What I’ve tried to do here is summarise the core concepts and I hope it is useful
Hiredgun.tech: Manage Security Groups from within a Power App
Microsoft: Dataverse Security