If one says “A”, he has to say “B”, right? So here is an addition to my yesterday’s “introduction to Microsoft Dataverse security model”. Hope you’ll find it useful, too.
In the basic security model, every user belongs to a business unit, and, when a role is assigned to a user, all permissions are applied in the context of the business unit which the user belongs to. Mind you, there are 4 levels of depth there, but two of them are business-unit specific (BU and parent-child BU), so I really mean those two.
Also, if a record is assigned to a user, it is automatically associated with the business unit which the owner belongs to (with the exception of organization-owned tables).
A usual problem in this scenario is giving users from different business units access to the data in other business units without exposing all of the organization data:
On the screenshot above, there is a role that gives full access to the account records in the business unit. However, since User 1 and User 2 belong to different business units, and since “Account Record” is assigned to User 1, how could User 2 see that record?
We can’t, always (if ever), use a hierarchy model to cover such scenarios, since relationships between User 1 and User 2 might be more complicated than those in the manager / position hierarchy. There are a few other options.We could:
- Create a team, put it in Business Unit A, grant permissions to that team, and put User 2 in that team. That way, User 2 will inherit team permissions in the Business Unit A. That’s great EXCEPT that, when User 2 creates a new account record, that record will end up in Business Unit B this time. So it’ll be User 1 who won’t be able to see that new account records this time around. Which means we may have to create another team in Unit B, put User 1 in that team, give permissions to the team… but what’s the point of having two different business units, then, if we are, essentially, merging the business units?
- Another option might be to rely on sharing. It could be direct sharing, or it could be sharing through the access teams, but, in either case, it’ll be all about explicitly sharing data owned by one user with the other users. This requires a lot of micromanagement, since (in the worst case) that kind of sharing may have to happen to every record in the above example
Matrix data access structure takes care of this problem on two levels. First of all, we can give our users security roles directly in the business units:
Even though User 2 still belongs to Business Unit B, that user has been given a security role in Business Unit A this time around. And, just like that, the user now has access to all account records in Business Unit A.
Also, if User 2 creates another account record, that record does not have to be associated to Business Unit B. “Owning Business Unit” field has been decoupled from the owning user in the matrix model, so that hypothetical account record can stay in the Business Unit A even though it’ll be assigned to the User 2. Notice how on the diagram below our “account record” is assigned to User 2, but it still belongs to the Business Unit A. Which means User 1 can still access it:
Which may still require some automation to set it all up properly (to keep records in the proper BU using an automated process, for example), but the possibilities are there.
Note: this is an excerpt from the learning materials for the “Power Platform Learning course” course. There is definitely more to say on this topic