Microsoft Dataverse security model intro

Not sure this overview of the security model in Microsoft Dataverse offers better/additional insight, but I came up with it anyways while working on the Power Platform course, so, hopefully, it’ll be useful.

In Microsoft Dataverse, security model operates with the following concepts:

• There is a Dataverse Environment – it has its own database, its own users, its own security roles, teams, business units, etc
• There are business units. Those are logical partitions where you can put users, teams, and child business units
• There is one root business unit in each environment – it does not have a parent BU. Other than the “root”, there can be any number of child business units (each of the “child” business units has to have a “parent”)
• Every business unit can have multiple teams. Every team can belong to only one business unit. There is a single default team per business unit. Users can be added to teams (teams cannot be added to other teams)
• Every user in the specific dataverse environment has to belong to one and only one business unit
• Security roles are not business unit specific – they belong to the environment, and they are assigned to the users/teams to grant access to data. Team security roles can be inherited by the users who are members of those teams
• Column security profiles are no business unit specific – they belong to the environment, and users/teams can be added to the column security profile to grant granular access to data
• Data records are not business unit specific – they belong either to the environment or to one of the “assignable” objects (a team or a user)

Dataverse will always ensure no user is able to access data they are not granted access to:

Dataverse will validate user access permissions in the context of the data action being requested. Access permissions in Dataverse are cumulative – permissions given through different roles & teams will be aggregated to perform the check above. Also, there are a few different types of access that may be given / requested, and data ownership has something to do with that as well.

Ignoring the column security profiles, since they are meant to secure individual columns, Dataverse will be looking at who owns the data, who it is shared with, and which business unit it belongs to when performing the access check:

And, of course, it will be looking at the permissions given to the user through the security roles assigned to that user directly, or through the security roles assigned to the user through team membership.

As far as possible “actions” go, there are 8 possible “actions” that can be secured in Dataverse per table:

• Create
• Read
• Write
• Delete
• Append
• Append To
• Assign
• Share

 

Except for the Append and Append To, the other ones are sort of self-explanatory.

Append “action” is all about adding a record to the N side of the relationship. For example,when  a contact is being added to an account through a 1:N relationship between accounts and contacts, that’s exactly appending contact to the account.

And that’s a separate permission that needs to be granted to the users through the security roles.

On the other hand, there can be a security role that’s giving “append” permission on a lot of different tables. Does it mean a user who has been given that role can append records in all those tables to any other table?

Actually, it’s a bit more advanced.

That same user needs to be given another permission, which is “Append To”, to append records from other tables to a specified table.

In other words, in that example with contacts being appended to the account, a user doing that has to have two permissions:

• Append (on the contact table. To be able to append contact records to other tables)
• Append To (on the account table. To be able to append to the account table)

Here is how security role configuration might look in the user interface:

There is, also, an agenda there, which explains what each circle means.

A “quarter” circle means that the permissions are given on the records assigned to the users.

A half-circle stands for the business unit.

A green “3 quarters” circle means business unit and child business units. Which is often called “parent-child business units”.

Finally, full green circle stands for the whole organization.

Default Dataverse behavior when a record is assigned to a user is to make user’s business unit the owning business unit for that record.

So, for example, if User A were to be assigned Contact 1, and if User B were in a different business unit, User B would need permissions to span across business units somehow to be able to access Contact 1. One option might be to grant User B access in the whole organization, of course. However, if User B’s business unit were a parent BU for User A’s business unit, then “Parent-Child” might also work. And so on.

And this is why this kind of security model is also called “owner-based” security. Do you remember how, when creating a table, you can specify table “Ownership” type, by the way?

This affects security in the following way:

• For the organization ownership, there will be no user/team owners. Records in such tables are owned by the organization, so permissions cannot be controlled at the owner / BU level. It’s either all or nothing
• For the user/team ownership, there is always a user/team owner. Which means permissions can also be controlled at the owner / BU level. Although, “all” permissions (in the whole organization) can still be granted

It does not end here, though. There are additional twists to this core model where we need to talk about hierarchy security, matrix data access, access teams, and more. And we’ll talk about it, just later.