Access Teams – why do we really need them?

By | August 9, 2017

What is the real difference between Access Teams and Owner Teams in Dynamics? Is it just that selection in the Team Type dropdown?

Maybe let’s start the other way around: what’s not different?

  • They are both represented by the same entity
  • We can add users to both types of teams
  • We can share records with both types of teams

So, if access and owner teams are that similar, why did Dynamics introduce Access teams at some point(there used to be Owner teams only in the past)?

This is where, if you have not read the following article yet, you probably should:

But I’ll try to provide a shorter version below.

The problem with the owner security is that there is a lot Dynamics has to look at to validate user’s permissions.

  • Every user will have security roles assigned to him/her directly
  • However, if a user has been added to a team, that user will inherit security roles from the team as well

Imagine what’s going to happen if there are 10 teams. Or, maybe, 100 teams. Or 1000.. Those security calculations can quickly become the one and only job Dynamics will be spending all server resources on.

There are two ways to make this situation better (other than to redesign the whole security model):

  • Create some sort of cache
  • Reduce the number of teams which have to be considered

And this is exactly what Dynamics is doing behind the scene. First of all, there is a security cache on the server. It’s calculated when the user logs in, and it stays there until it needs to be recalculated. There a few reasons why that kind of cache may have to be recalculated, but, essentially, it’s all about changing the set of security roles which the user has. For example:

  • A security role can be assigned to one of the teams where this user is a member
  • User’s membership in the teams can be updated

If that happens, security cache will be recalculated (and that will take a bit of time – you may notice a slowdown when navigating to another page in Dynamics at that moment). As far as security cache is concerned, that’s more or less how it works.

However, Dynamics is also reducing the number of teams that can affect that cache by introducing the Access Teams. Because, you see, you cannot assign security roles to the access teams. So there is no need to do anything with the security cache when such a team is created and the users are added to the team.

The way I see it, that’s the one and only reason why Access Teams were introduced in Dynamics. Otherwise, the system could just keep using Owner teams where it currently requires an access team. It becomes really critical when you start thinking about the team templates and “sharing” in general. For every team template, there can be one team per record in Dynamics. Imagine 10000 opportunities in the system, each having it’s own access team.. IF those were owner teams, it would be a very tough scenario for the security cache calculations. With the access teams, Dynamics can just ignore them when doing those calculations (yes, it still has to calculate access granted through sharing.. But, at least, it can safely assume those Access Teams won’t have any security roles).

So the difference is not, really, that we cannot assign security roles to the Access Teams.. or that we cannot use Owner Teams with the team templates.. those characteristics of the Access/Owner teams are there because of how these two types of teams are supposed to affect Dynamics performance. Owner Teams will affect the cache directly, so we should not be using them for sharing that much. Access teams can be completely ignored from the security cache calculations standpoint, so, if we want to use record sharing with teams, we should be using Access Teams for that.



Leave a Reply

Your email address will not be published. Required fields are marked *