Security concepts in Microsoft Dataverse
Associate a business unit with an Azure AD security group
You can use an Azure AD security group to map your business unit for streamlining your user administration and role assignment.
Create an Azure AD security group for each business unit and assign the respective business unit security role to each group team.
For each business unit, create an Azure AD security group. Create a Dataverse group team for each Azure AD security group. Assign the respective security role from the business unit to each Dataverse group team. The user in the above diagram will be created in the root business unit when the user accesses the environment. It's fine to have the user and the Dataverse group teams to be in the root business unit. They only have access to data in the business unit where the security role is assigned.
Add users into the respective Azure AD security group to grant them access to the business unit. The users can immediately run the app and access its resources/data.
In the matrix data access, where users can work and access data from multiple business units, add the users to the Azure AD security groups that mapped to those business units.
Owning Business Unit
Each record has an Owning Business Unit column which determines which business unit owns the record. This column defaults to the user’s business unit when the record is created and cannot be changed except when the feature switch is turned ON.
Note
When you change which business unit owns a record, be sure to check out the following for cascade effects: Using Organization Service to configure cascading behavior.
You can manage whether you want to allow your user to set the Owning Business Unit column when the feature switch is ON. To set the Owning Business Unit column, you need to grant the user’s security role the Business Unit table’s Append To privilege with local level permission.
To allow your user to set this column, you can enable this column in the following:
- Form - both the body and header.
- View.
- Column mappings. If you are using the AutoMapEntity, you can specify the column in your column mapping.
Note
If you have a job/process to sync data between environments and the Owning Business Unit is included as part of the schema, your job will fail with a Foreign KEY constraint violation if the target environment does not have the same Owning Business Unit value.
You can either remove the Owning Business Unit column from the source schema, or update the Owning Business Unit column value of the Source to any of the business units of the target.
If you have a job/process to copy data from an environment to an external resource, for example PowerBI, you will need to select or deselect the Owning Business Unit column from your source. Select it if your resource can receive it otherwise deselect it.
Table/record ownership
Dataverse supports two types of record ownership. Organization owned, and User or Team owned. This is a choice that happens at the time the table is created and can’t be changed. For security purposes, records that are organization owned, the only access level choices is either the user can do the operation or can’t. For user and team owned records, the access level choices for most privileges are tiered Organization, Business Unit, Business Unit and Child Business Unit or only the user’s own records. That means for read privilege on contact, I could set user owned, and the user would only see their own records.
To give another example, let’s say User A is associated with Division A, and we give them Business Unit level Read access on Contact. They'd be able to see Contact #1 and #2 but not Contact #3.
When you configure or edit security role privileges, you're setting the access level for each option. The following is an example of the Security Role privilege editor.
In the above you can see the standard privilege types for each table Create, Read, Write, Delete, Append, Append To, Assign and Share. You can edit each of these individually. The visual display of each will match the key below as to what level of access you've granted.
In the above example, we have given organization level access to Contact which means that the user in Division A could see and update contacts owned by anyone. In fact, one of the most common administrative mistakes is getting frustrated with permissions and just over granting access. Very quickly a well-crafted security model starts looking like swiss cheese (full of holes!).
