Record ownership across business units (aka “matrix data access structure”) – it’s here now

I’ve been diligently checking for this setting in my admin portal a few times per week lately, and, finally, it has arrived:

Before you proceed, you might want to read my earlier intro post for this feature:

https://www.itaintboring.com/dynamics-crm/matrix-business-units-the-cool-new-way-of-setting-up-user-security-in-microsoft-dataverse/

In this post, I’m just going to show how this works.

First of all, don’t be surprised to see progress indicator spinning there for a while once you have enabled that feature in the admin portal – just give it some time to complete.

Once this is enabled, I can go to the admin portal and start assigning security roles to the users in the specific business units. As in, I can choose a business unit, and, then, I can assign roles:

Compare the screenshot above to the one below, which is from the environment where this new feature has not been enabled yet, and you’ll see the difference:

In those environments, I can’t pick a business unit to assign a role to my user (essentially, those roles will always be assigned in the user’s BU).

What is it giving us so far, then?

Do you have users from one BU who need access to certain tables in another BU? Create a security role, configure permissions, then just assign that role to your users directly in the business unit, and they’ll get access to those tables.

You don’t need to worry about creating access teams. You don’t need to implement record sharing.  You can just start permitting users to access data in other BU-s by giving them roles in those BU-s. Essentially, we can, now, create “guest users” in various business units.

What it does not solve, yet, is the ownership issue. By default, when you have a user-owned table, a record created in that table will be assigned to the creator, and its “owning business unit” column will be set to the business unit of the owner. Which is not, always, what we might want to happen to the records created by those “guest” users – instead, we might want the business unit to keep owning those records.

This is because we might still want regular business unit users (those who belong to the BU) to have access to such records, and, from that standpoint, nothing has really changed – there are, still, the same access levels:

• Owner
• Business Unit
• Parent-Child Business Units
• Organization

This is where the second part of this new feature comes in, since we can add “Owning Business Unit” column to the form (or, in general, we can manipulate that column).

Note: as of Nov 22, at least in the Canada region, when a new form is added to the environment, “owning business unit” column might not get exposed. This will be fixed, but, for now, if you don’t see that column in the form designer, just use a pre-existing table/form to keep experimenting with the new security model.

Let’s add it to the form, then:

Now when creating a record in the model-drive app, I’ll be able to pick the BU for my new record:

Or, if I leave it empty, it’ll be set to the BU of the owner by default:

That’s, basically, how it works, but, from there, we can get into all the different scenarios. For example, let’s say I wanted to assign that record to another user.

I might or might not be able to do it depending on whether that other user has permissions in the target BU.

For instance, in the below scenario I have that record assigned to myself, it’s in the “Test” BU, and I’m trying to assign it to another user:

Apparently, on my other user does not have permissions in the BU. Which is fine – I could give that user required security roles in the target BU and that would work even if the user belongs to another BU.

Here, let’s give that user a role in the Test BU:

And let’s confirm that the user belongs to the main BU:

The security role is only giving access in the BU, so, normally, it should not work (since the record is in a different BU):

But, with this new model, since the user has that role assigned to them directly in the BU, it should all be good now. Let’s try:

Oops… is that an error again?

The problem now is that, by default, records are automatically moved to the owners business unit. In order to change that behavior, we need to update organization settings and set “AlwaysMoveRecordToOwnerBusinesUnit” to false

Those cascading behaviors are described in more details here:

https://docs.microsoft.com/en-us/powerapps/developer/data-platform/configure-entity-relationship-cascading-behavior#about-the-assign-action

With that done, I can finally save my record so it’s assigned to a user, and, yet, it still belongs to a different business unit:

Do we want to always change that setting so that the records are no moved to the owner’s BU? Guess it depends, but you’ll need to keep this in mind when designing your security model. After all, that setting is “all or nothing” – it can’t be done per business unit/per user. So, an alternative might be to set it to “false” for the org, and, yet, to use a flow/plugin to maintain default/legacy behavior for some of the business units, for instance.

Well, I’m pretty sure there are other edge cases and caveats we may need to think about when working with this new model, but I’m hoping this was useful so far to get you started.

Would also recommend this video by Paul Liew: https://www.youtube.com/watch?v=NBBYinF9B7g&feature=youtu.be

Or yet another one by Scott Durow: https://www.youtube.com/watch?v=dVGklfmVr6s

Have fun!