A guide to help you determine the best solutions for you.
Microsoft Dynamics CRM Owner Teams vs Access Teams
In Microsoft Dynamics CRM 2011, the Team concept that was used is now known as Owner Teams in Microsoft Dynamics CRM 2013. The new version of CRM also introduces a new team type called Access Teams. Two fundamental differences between an Owner Team and an Access Team involve ownership and sharing. As the name implies, a member of an Owner Team inherits permissions to the records because the team owns the record. Access Teams are different in that permissions are granted to the records via sharing.
Now that there are two team types, when should you use one over the other? Since owner teams are a known concept with the two previous releases of CRM, only the best practice of when to use them will be defined in comparison to access teams.
- Best where teams access high volumes of data, via ownership or business unit access
- When a security role is required to access records scoped by a business need
- Teams used as service scheduling resource must be owner teams
- Rapidly changing team memberships
- Allows for >1,000 team memberships per user
- Individual record based access
- Owner of the record allowed to define access to other users
- Can accommodate varying levels of group access types to records
Microsoft refers to an access team, as a lightweight team specifically designed to accommodate high volume sharing scenarios. One benefit for using Access Teams is the simplified administration. After an access team template has been defined for an entity, the team is created for you automatically and membership is managed by simply adding or removing users to the team sub-grid on the form, and that’s it. All of the sharing permissions defined in the template configuration are automatically imposed for all records for that entity granting all team members the applicable permissions.
Since access teams do not require a security role, using access teams can reduce the overhead in scenarios where one is not needed. The overhead being referenced here requires further background information. Keep in mind that security roles are cumulative, so the permissions defined in both the roles of the user and the team factor in. In an effort to mitigate any impact of this overhead, the system will cache the cumulative permissions for each user when they log into CRM. This cache will get flushed due to inactivity or a server restart, which in turn can cause a delay in the initial connection when the user logs in, if they have a large number of security roles and/or teams with security roles. Also, whenever team membership changes or the security roles for the team change, the user’s cache will get flushed and re-calculated on the next log on. In a rapidly changing environment, this can introduce significant performance impacts to the system. Therefore access teams without a security role, which avoid this performance impact potential, are recommended for this type of environment.
Another area of overhead access teams help avoid deals with the Principal Object Access (POA) table. The POA table records all of the sharing rules between users/teams and each entity. Each record in this table defines the permissions between the User/Team and the entity records with which it has been shared, including the ability to read, write, assign, share, etc. as well as the privileges that have been inherited from any cascading share that is held separately from the explicit privileges. By using access teams, this approach can significantly reduce the number of records needed in the POA table.
As shown in graphic above, a small team with just two members can reduce the overall number of shares by fifty percent. Instead of two share records needed per entity record, only one from the team to the entity record is required. In the case of larger groups, the benefits to the POA table can be exponential.
For rapidly changing environments where ownership is not needed, access teams can provide many benefits. Access teams are also easy to manage access to records which may not explicitly defined by a security role. Lastly, keep in mind owner teams and access team can be combined to take advantage of both access team and owner team benefits.