Dataverse Teams: A Triple Threat

A few posts ago, we touched on how you can drive environment access using Entra ID Security Groups.

In today’s post, we’re going down a similar path, but this time, we’re driving Security Roles with Dataverse Teams using Entra ID Security Groups. But first off, let’s talk about what Dataverse Teams are.

 

What Are Teams

Dataverse Teams are a simple way to share business objects across business units and streamline user privileges in larger-scale environments. Despite assigning a team to a specific business unit, this does not prevent other users across other business units from being part of a team. Teams can also assist with driving security role assignment across their members, meaning that users now belonging to a team inherit the security role associated with it.

When it comes to creating Dataverse Teams, there are a variety of options you can choose from:

Owner Team

When you create an owner-type team, that team becomes the owner of records created by users assigned to that team and thus has full privilege rights to its owned records. You can associate security roles with an owner-type team so members can inherit the role, but users can also make use of individually assigned security roles as well.

 

Access Team

An access-type team works slightly differently than an owner-type team. An access-type team will not own any records its members create but rather allow its members to share records with the team, which then allows other members to have read, write, and append privileges. Access-type teams can also be assigned to a Dataverse table, resulting in the team members being able to interact with data in that table. This bypasses the need to share the record with the access-type team manually. Access type teams do not have security roles assigned to them, and therefore members are reliant on their personal security role associations and do not inherit any additional privileges from the access type team.

 

Entra Group Team

These are fun ones. Entra-group teams are slightly similar to owner-type teams. Entra group teams are driven by Entra ID Security Groups or Entra Office Groups. When an Entra group team is associated with either a security group or office group, the security group or office group controls member access. This means that the Entra group team inherits the security group or office group members/owners instead of adding them manually. Furthermore, when you associate security roles with an Entra group team, the members governed by either the security group or office group then inherit the security role as well. Once a group and related security role are set, we can expect that when a new user is added to the Entra ID security group, the user will become a member of the linked Entra group team and will also inherit the assigned security role.

 

When it comes to creating an Entra group team, the membership type works slightly differently:

• Members and guests: This includes both member- and guest-type users that belong to the groups Members category.
• Members: This includes only the member-type users that belong to the groups Members category.
• Owners: This includes only the member-type users that belong to the groups Owners category.
• Guests: This includes only the guest-type users that belong to the groups Members category.

A visual breakdown of what these membership types refer to can be found under the Manage Group Teams section in Microsoft Docs relating to Power Platform Security and Governance.

Remember when we said that Entra group teams are similar to owner-type teams? Let’s discuss that a bit more.

Scenario 1: Say we assign a security role to an Entra group team. This security role has team privileges. All members that this team inherits will also inherit this security role, and records that they create will be team-owned. They can then access the records that the team owns.

 

Scenario 2: Say we assign a different security role to an Entra group team. This time, the security role has user privileges. The members the Entra group team inherits now also inherit this role, but when they create a record, the record is user-owned, not team-owned.

 

Some Frustration

In a scenario where a new user is added to an Entra ID security group that is linked to an Entra group type, one would expect that the user will sync to the group as a member and get assigned the team-associated security roles. You’re not far off. Using a Force Sync User action in a flow to sync the new user in the Entra ID security group to the environment will work; however, the security role will only take effect once that user physically logs into that specific environment. So if you have a process where you need to assign records to a user that has not entered the environment yet and their supposedly role gives them access to that table, the process will break as the user has not synced with the role just yet and thus does not have any privileges to tables.

The work around this is to update your Force Sync User flow to get the user id from the User table, get the role you wish to associate with them (remember to select the right role in the same business unit as the user), and use the Relate Rows action on the Users table to relate the role to the new user. This will result in the user now having a forcefully associated security role before they enter the environment, and they can therefore have record assignments and other processes occur in their name. Just remember, when relating the security role to the user, be sure to use the roles ODataId field in the Relate with field.

 

A Point Missed

If you’ve made it this far, thanks for sticking around.

In my previous post, we discussed setting up security roles effectively. There was a point I missed that I feel needs to be shared.

When a security role is assigned to a user, either individually or through a team, the role assigned to the user needs to match the role within their assigned business unit. We briefly discussed how when a role is created under the parent business unit, it automatically cascades to all the child business units. This being the case, if a user was assigned a role and lived within business unit A, if we were to move them to business unit B, the security role association will break as the roles business unit no longer matches the user’s new business unit. This results in the security role being removed from the user and needs to be re-added manually.