The teams feature was introduced as part of a solution to help people more easily collaborate within a group business context. Prior to teams, customers found it challenging to create the proper security configuration where the owner of a record wasn’t necessarily a single person. In many scenarios, people need to be able to operate as a team as opposed to on an individual basis. Access teams, which was introduced in Dynamics CRM 2013 was meant to solve yet another variation of the group security challenge and is a strategic option when it comes to data security.
The Benefits of Access Teams
When the teams features was updated to include security roles it gave us more power to accommodate scenarios where there was a group business context. For example, while some sales scenarios require individual salespeople to have their own security context there are also times when sales are performed from a team perspective. Often times in more complex sales situations multiple people contribute to the effort. In such instances, it tends to not make sense for an individual to be the owner of the sales data. A team created for the purpose of providing the same access to all members can work well in this situation. Yet there are still other scenarios that are challenging to accommodate with owner team functionality.
Access teams offer a more granular level of access to records that isn’t possible with owner teams. For example, we may not want to give each team member the same level of access to the data. In this case, we would have to resort to sharing the data with any team member that shouldn’t have full access. The challenge this presents is that each team member that required anything less than equal access would require a record share. Record sharing has system performance implications which is why we should always do our best to minimize sharing. In extreme scenarios, we could end up having a large amount of data that has been shared with a group of people which inevitably begins to impact performance system-wide. Access teams using team templates allows us to create a more granular security model where we segment what access a team member is given, but with a lesser impact as we would have shared with each individual. For example, if we have a group of people that should only have read access we can create an access team template that only grants that privilege only.
Access teams allow for access to specific data as opposed to all data owned by a team. If you created a system using an owner team model then any user that is a member of a team will see all records the team has access. This isn’t always the desired outcome. Sometimes we want users to only have access to specific records. Owner teams don’t accommodate this situation forcing us to resort to a standard record sharing tactic.
Access teams provide a more intuitive method for users to grant access to other team members and accommodate variable team membership situations. There are times when the team members can vary or change often. Access teams when setup correctly allows for users to view a data grid on the user interface of team members. This makes it clear who has been given access and also makes it easier to add or remove team members. In an owner team scenario, users would need to navigate to the team record itself and add or remove members which is more cumbersome especially if members can change frequently.
Access team life cycle is managed automatically by the system. Teams aren’t created until the first member is added to the team. In like fashion when the last team member has been removed the team and its corresponding share is removed. This sounds great in theory, but unfortunately, in real-world scenarios, I’ve never seen where team members were ever completely removed from a record. Most often these records remain intact and therefore the share and the team remain in the system for all time until the data is eventually archived.
How Access Teams Work
When you choose to go with an access team strategy as opposed to an owner team strategy it’s effectively a trade of record shares for teams. What I mean by this is in situations where you might need to share a record with 10 users and end up storing 10 share records in the Principle Object Access (POA) table you end up only having 1 share record in POA with an access team. The reason for this is when an access team is created those 10 users that needed access are part of a team and there is a single share to the team. This effectively achieves the same result (in this case). The trade comes in where we’ve saved 9 share records, but we created 1 team record instead. If I can accomplish this trade on a large scale I’ll take that any day of the week over record shares because of the performance impacts.
Access teams don’t have security roles, therefore, they achieve their security context through the record share. When you share a record you can choose what privileges are granted along with that share. This is one of the reasons why an access team doesn’t need security roles. The main purpose of the team is simply to provide the group mechanism for the share privileges.
As mentioned earlier access teams are system managed so they are created and removed automatically. This can be convenient in situations where you find yourself with a lot of teams that have a temporary business context and you want to remove them eventually. Access teams could potentially address this kind of requirement, but it appears it is rare that users will ever remove people from an existing team. You may, of course, choose to perform this action problematically if it makes sense.
Access Team Performance Pros
In situations where users may be part of a large number of teams, access teams can provide a performance benefit over owner teams when it comes to security privilege caching. An access team is similar to an owner team in that a record is created in the team table, but unlike owner teams, it doesn’t provide any privileges from security roles. Access teams are granted privileges through the related record share instead of role privileges.
Security privileges for users are cached on the servers so that they don’t have to be queried each time a user performs an action. The cache is created when a user logs in and discarded when a user is idle for a period of time. The challenge is if the user is a member of a large number of teams this caching operation can take some time. Since access teams don’t have privileges of their own they don’t impact the security caching operations. When we use the phrase “large number of teams” the standard number give is around 1,000 teams, thus if you think users will be on significantly more than 1,000 teams you may want to consider if access teams may be a better option.
Access teams allow for variable team composition without server caching impacts. If you have a system where the team members have a high rate of change then access teams may be a better option. Whenever a user’s security context changes the servers regenerate the security cache. This means that if you frequently change user security roles, team memberships or team security roles the server caches are being impacted. This can cause a significant load on a system in enterprise scenarios with thousands of users.
Access Teams Performance Cons
The good and bad thing about access teams is they provide their functionality through a hidden record share between the target record and the related access team. An access team is similar to an owner team in that a record is created in the team table, but unlike owner teams, it doesn’t provide any privileges from security roles. The challenge faced is in calculating how many shares you may end up with when using access teams.
Each record share in the system is represented as a record in the Principle Object Access (POA) table. This table is a choke point within the system because it impacts all user-owned entities. In a scenario where we have a lot of data and a lot of sharing requested our POA table growth can be exponential. Depending on the security model of the system it’s easy to create a situation where the POA table grows so fast that in a matter of months the system performance has become an issue.
Access teams can create exponential sharing scenarios through related entities. One situation I ran into with access teams was that I need to give team members access to additional related entities within the same privilege level. The challenge with this is the team has access to the record through a record share. If you have related data you need to share that data as well or else the team won’t have access to it. This means we’re back in a possible exponential share situations depending on the cardinality of the related data. For example, if I have a related entity that has 10 rows then each of those 10 rows would need to be shared to the access team creating 11 total shares including the team share. This is not a great situation to be in if you expect to manage a large amount of data in the system.
Access teams is a great feature that we can use where it strategically makes sense. It provides options to the system designer that would be challenging to accommodate with owner teams. Knowing how access teams work is the key to having a better idea if they make sense for your situation. We should also be very aware of the potential performance impacts that we may expose ourselves to when we do choose to use this feature. Like any other feature that gives us more flexibility, we must bear the responsibility of using it with care.