Access Teams vs Owner Teams

Let’s start with the basics: a team is a group of people. In real life, as it is in Dataverse, we need to make groups of people better manage them, allowing them to access someplace and giving them ownership of a thing.

This article is an addition to the previous article I wrote on security roles, many concepts are already been said there, so if something sounds unfamiliar, please read it here

Owner teams

An owner team is a team that can own something. It is the most common form of team and somebody can live happily not knowing there is another form of team. This is a guide on how to create it.

This kind of team has to be defined upfront, it is not meant to be dynamic. We can think of an owner team as a group of people that needs to manage a certain object and they will (almost) never change. For example, the people that are involved in a quotation process. Let’s suppose that we have users that have to manage quotations under different business units, for example, because BU is geographically divided in our organization. Thus all the quotation users will be grouped into a “quotation” team that is defined upfront.

The main feature of the owner team is that it has a security role assigned. This security role is then applied to all the users that are part of the team itself. This is fundamental to understand.

Sometimes debugging a behavior of the platform that is not expected we tend to forget that users can be part of teams that have security roles and if the role is high enough, the users are entitled to do actions that should never be possible to them.

Once there was a limit of 1000 teams per user. This means that users can be part of only 1000 teams. This limit has been removed, but being part of multiple teams (my suggestion here is to not exceed 100 teams) is a performance issue, and should be avoided. This is because the system has to evaluate all the roles that are assigned to the user before deciding if an action can be performed or not. Since all teams have their security group this can be an operation expensive in terms of resources.

The owner teams can be linked to an AD group. This can be particularly useful to automate license and role assignments. Keep in mind that the user is added to that team only after the first login.

Access teams

Access teams were originally created to overcome the limit of 1000 teams per user, as I wrote before. They are managed differently by the system and can be useful in certain architectural designs.

Creating an access team can be quite complex, and I suggest reading the official documentation for this here

Two concepts are important to keep in mind:

• Access teams are dynamically created and strictly related to a record
• Access teams don’t have a role, they use the share mechanism under the hood

The typical example of an access team is the account team of a customer. This team has to be created as soon as the customer is created in the system, and the people who are managing the customer can be different, and need to keep their own security role, even if they need visibility on the customer.

If we think about the definition of the sharing mechanism that I’ve explained in my previous post, we can see that the access team is doing exactly that.

If on one hand, the access team is not making the system search for additional roles assigned to the users, on the other hand, it is increasing the rows in the POA table.

As always in the IT world the blanket is short, if we cover our feet we have our head freezing and the other way around.

In conclusion

It is extremely important to be aware of the possible teams that are available in Dataverse/Dynamics365 and also be aware of their limitation and characteristics.

There is no straightforward answer on what to use and it depends on the specific situation. It is important to have the best mix taking the best from the two.