I’d like to break down the difference between two types of teams found in Microsoft Dynamics CRM 2013. Most people who are familiar with teams in Dynamics CRM know about what are called, “Owner Teams.” These are the traditional teams that have been around since CRM 4. In Dynamics CRM 2013, Microsoft has introduced a new type of team called an “Access Team.” The purpose of creating Access Teams appears to be for the benefit of working around and with some of Dynamics CRM’s security features.
The original Owner Teams are created and managed by Users in Dynamics CRM. These teams have an administrator and contain members. The members are static and do not change often. An example could be the Sales Team in the southeast region of the United States. These members may change as the territory expands or as positions in that region experience turnover, but for the most part they stay the same. The teams also have Security Roles which provide additional access and permissions to members of the team. A user might only have access to view and edit their own Opportunities but as a member of a team they can be provided access to all Opportunities within their Business Unit if the team is provided the permissions. Additionally, Owner Teams have the capability to own records in Dynamics CRM hence the name. This team ownership of a record allows for sharing to occur amongst the team members.
While Owner Teams did a lot to help provide users with the information they needed there were some flexibility issues surrounding these Owner Teams. Suppose you wanted to have a specific group of people handling various high-level customers or deals but that team would vary based on the deal or customer. This would require creating and managing a separate team for each customer or opportunity you wanted to share amongst the group. With large companies, teams of this sort could grow quite numerous which adds additional taxation on the system since it would need to verify access based on the security role of the team each time a record is opened.
To help resolve the performance impact of team security being loaded and calculated constantly Dynamics CRM 2013 introduced Access Teams. Unlike Owner Teams, these teams are not given a security role nor do they have the capability to own records. The method of access is performed on a per record basis through sharing permissions. Being granted permissions to an access team for a record will cause CRM’s normal cascading behavior to trickle down to any related records. The sharing is different than a normal share in that share permissions aren’t shown to the end user and are not able to be modified but are managed and set up by an Access Team template. Additionally, instead of having to create a team ahead of time, the access team is generated upon the first member being added to the record and is deleted when the final member is removed from the team. Keep in mind that the only way to remove an Access Team is to remove all of the members. This feature can lead to a large number of record sets being created for the Access Teams and requires consideration as to its possible performance implications.
SCOTT FLORANCE | CRM Business Software Consultant
Scott Florance is one of the CRM Consultants at KTL and has proven his value as a member of the team since September 2013. Whether implementing a new CRM organization or adding to existing configurations, Scott has engaged clients with a positive and enthusiastic demeanor to help them meet their organizational needs. With four plus years of experience, Scott is familiar with CRM as both a power user and administrator. Scott received his bachelor’s degree in business administration from the University of Central Florida. He is a Microsoft Certified Technology Specialist for Dynamics CRM as well as a Certified Scribe Technician.
