Adventures with Dataverse: Fun with Business Units and Access Teams

I had a customer ask me for a recommendation on how to model security for Dataverse tables for a specific use case they had.

Let me set the stage, starting with Dataverse tables.

• Business Units, different from the Power Platform Business Units, but those will come into play.
• Locations, each Location was associated to a single Business Unit.
• Projects, each Project was associated to a single Location, which would lend itself to determining the Business Unit, which I was going to need.

In an attempt to minimize confusion, I will call the Business Units native to the Power Platform, Power Platform Business Units, and the custom Business Unit records, Business Units.

Now for the security requirements.

These took me a while to wrap my head around. 😕

• Some Users have full control for all the records.
• Some Users have read-only access for all the records.
• Some Users have full control for all the Project records where there are the Owners.
• Some Users, depending on the Location of a Project, also have full control for all records that belong to that Location.
• When a Project is completed, all User permissions, except for those that have full control over all the records, needed to revert to read-only.

After much trial and error, more than I care to admit, this is the solution I came up with.

I created (3) Security Roles.

• Administrators have Organization permissions for all privileges for all the custom Dataverse tables.
• Readers only have Organization permissions for Read privileges for all the custom Dataverse tables.
• Contributors have User permissions for most of the privileges for Project records, and have Organization permissions for the privileges Read, Append and Append To, for the Business Unit and Location records.

The next thing I did was create a Power Platform Business Unit for each of the Business Unit records in the custom Dataverse table.

Whenever you create a Business Unit in the Power Platform a Team is also created.

The one thing that is nice about Business Units is that the relationship between User and Security Role is unique for each Business Unit.

I added the Security Role of Reader to Demo Manager for the top-level Business Unit, in this example, called POC 2 Business Unit.

One thing I had to do first, was make sure that each Project was assigned the correct Power Platform Business Unit upon creation, this would be dependent on the Location, which was associated to a Business Unit.

To make this work, I set the Owning Business Unit of each Business Unit to the Power Platform Business Unit.

I then created a Power Automate flow that would run whenever a Project was added.

The flow would look up the Business Unit based on the Location, and then set the Owning Business Unit to the same Power Platform Business Unit as the Owning Business Unit.

Now Demo Manager has Read access to all the Projects.

I confirmed my expectations in my Model-Driven App, Demo Manager could indeed see (Read) all the Project records, but could not do anything else, such as, Write or Delete.

For Users that needed full control of the custom Dataverse tables, I followed the same process for setting the Security Role as I did for Demo Manager, but the one change I made was to set the Security Role to Administrators, instead of Readers.

Now to the tricky part.

I assigned the Contributors Security Role to Demo User for the Business Units, Business Unit 1 and Business Unit 3, I don’t want Demo User to have any access to Projects in Business Unit 2.

Just for kicks and grins I created five Projects across the three Business Units.

I verified that Demo User could only see Projects from Business Unit 1 and Business Unit 3.

Right now, Demo User can only edit Projects that they own, but our requirements say they need to be able to edit any Project in a Power Platform Business Unit they have access to.

Easy enough, I could just set the permission of the Write privilege to Business Unit. The challenge is, that once the Project has its State set to Completed, I need to remove all privileges except for Read.

Unfortunately, this is not going to work, because this applies to all Project within the Power Platform Business Unit, where I need it to apply to each Project record individually.

Enter Access Teams.

An access team doesn’t own records and doesn’t have security roles assigned to the team. The team members have privileges defined by their individual security roles and by roles from the teams in which they are members. The records are shared with an access team and the team is granted access rights on the records, such as Read, Write or Append, and therefore access team members cannot create records using the access rights of the access team. User is required to have a security role with Create privilege to create records.

Use access teams and owner teams to collaborate and share information (Microsoft Dataverse) – Power Apps | Microsoft Learn

When is the right time to use Access Teams?

• The teams are dynamically formed and dissolved.
  • This typically happens if the clear criteria for defining the teams, such as established territory, product, or volume aren’t provided.
• The number of teams isn’t known at the design time of your Dataverse system.
• The team members require different access rights on the records.
  • You can share a record with several access teams, each team providing different access rights on the record.
  • For example, one team is granted the Read access right on the account and another team, the Read, Write and Share access rights on the same account.
• A unique set of users requires access to a single record without having an ownership of the record.

Use access teams and owner teams to collaborate and share information (Microsoft Dataverse) – Power Apps | Microsoft Learn

I created an Access Team for each Location.

I then added Demo User to the Access Teams that align with the Locations they need Write permissions to for the Projects.

I now needed to update my flow for when a Project is added to Share the record with the appropriate Access Team, but before I do that, I need to align the correct Access Team to the Location. To do this, I add an Access Team column to the Location table that is a Lookup to the Teams table. I then updated all the Locations with the correct Access Team.

Now I can update my flow with a Dataverse action Perform an unbound action.

• I set the Action Name to Grant Access.
• I set the Target to the OData Id of the Project.
• I set the PrincipalAccess to the required JSON as shown in the figure below.

One thing to note, when you first enter the JSON for PrincipalAccess you will need to use two @ symbols to get it save correctly, so enter @@odata.type instead of @odata.type.

Now let’s add another Project and see if the Demo User gets Write access.

I jump back to the Model-Driven App for the Demo User and can see the Project, click into the Project, and as expected, I can edit the Project now.

But now, what about when the Project is completed, when Project Status is set to Completed.

I created another Power Automate flow to handle this, it changes the access to Read and sets the Project record Inactive.

Now, the one thing to call out, even though Status is Inactive, and the record is in Read mode, the Owner of the Project record could Activate the Project record and make changes.

If you didn’t want this ability, then you would need to change the Owner of the record to a different Team, maybe a Team called Archived.

There is a lot of power and flexibility when it comes to security in the Dataverse, figuring out the right approach is often where the struggle is at.