Adventures in Microsoft Dynamics CRM 2013 Access Teams

One of my favorite new features in Microsoft Dynamics CRM 2013 is Access Teams. For an explanation of Access Teams, see our Fourth Day of CRMas post here. The thing that is so game changing about Access Teams is that they allow you to grant specific access permissions to a team without having to set the team up beforehand. This makes them ideal for dynamic team scenarios,such as team selling, where you have a group of people managing an account, and the group is different for each account.

If you use owner teams for these scenarios, it can be very cumbersome. You would have to create the team manually when you create the account, then either share or assign the account to the team, then add the members. Access teams take care of all of this for you. They are super easy to set up, and make managing team membership very easy, since you just have to add people to the subgrid.

Having lived with Access Teams for several months now, there are a few interesting things I have learned about Access Teams, which helped to clarify for me where Access Teams are a good fit, and where they are not. The following things may surprise you about Access Teams.

1. You can control who can add members to the Access Team subgrid. Only users with share privilege for the entity on which the access team exists can add or remove members from the Access Team subgrid. This makes sense—by adding people to the Access Team, you are in effect sharing the record with the people on the team.
2. Access Teams are still teams, and the record is shared with the access team. This means that normal cascading behavior exists between access teams and child records of the record with the Access team. So if you have the normal cascading for sharing enabled in the relationship between Accounts and Opportunities, and you add an access team to an account with read access, any opportunities will also be readable by members of the Account Access Team.
3. You can programmatically manage the membership of access teams, but the team isn’t created until the first member is added. This is for performance reasons—Microsoft doesn’t want to load the system down with record teams if no members are a member of the team. This means that if you are having a data integration add members to record teams, if a record has not had any members added to its access team, a team record won’t exist, so you can’t just create a team member record. And while you can manually create a team record with an team type of “access team,” manually created access teams cannot be linked to records for security purposes. There is an SDK process for adding the initial member to an access team, which also creates the Access Team. See this excellent post from Inogec with the details of how to programmatically add the initial Access Team member.But what if you don’t want to write code, and you just want your integration to create the Access Teams, if they don't already exist,  so theat you can add members to them? The only integration adapter that currently supports creation of system Access Teams is the Kingswaysoft SSIS Adaptor.
4. You can manually create Access Teams and also convert Owner Teams to Access Teams. However, user created Access Teams cannot be used in the same way as system created Access Teams. For example, you can’t manually create an Access Team and link it to an Access Team Template. So why would you want to manually create Access Teams? The reason is Owner Teams carry some extra overhead—they have queues, security roles, they can own records, they are a bigger deal. Access Teams are a lightweight team, without the queues and ownership qualities. So if you just want a team to group users or share a record , but don’t need the extra functionality of an Owner Team and will never need the team to own records, an Access Team is a faster, lighter way to go. Just remember that if you create the Access Team manually (and not through the system created Access Team method), it can’t be used with Access Team templates from a form.
5. You can have multiple Access Team profiles per entity. For example, you want to grant users either read permission or read-write permission. You can create two Access Team Templates associated with the entity, add two subgrids, and associate each subgrid with one of the two Access Team Profiles. There is a limit of two Access Teams per entity.
6. Access Team Template records cannot be moved between environments as part of a solution. This is important, because when you use Access Team Templates, the subgrid on the form references the Access Team Template ID. If you move your form customization and the Access Team Template referenced by the subgrid does not exist in the target CRM environment, your Access Team subgrids won’t work. Even if you manually create Access Team Templates that match the same name  as in your original environment, the subgrids will still not create Access Teams. The answer is to move the Access Team Template data records when you move your customization, making sure that you preserve the existing record ID/GUID. These records live in the teamtemplate entity, and can be moved with any good ETL tool.
7. You cannot share records with system created Access Teams. Behind the scenes, when the system creates an Access Team, it is sharing the privilege defined in the Access Team Template with the Access Team, and cascading sharing for any relationship with cascading share privilege enabled. However, you cannot manually share additional entities with that Access Team. This is a by design limitation. Access Teams were designed to be lightweight, easy to delete teams, so Microsoft intentionally limited how they could be shared. Knowing this limitation helps clarify when Access Teams should be used, and when you should consider a different solution in CRM. Consider two scenarios:
   • You have a sales team on an Account. Anyone on the sales team should be able to see related Opportunities and Contacts. In this scenario, Access Teams are a great fit, because standard cascading will grant Access Team members permission to read opportunities if they are on the account sales team.
   • You have a sales team on an Account. Anyone on the sales team should be able to see related Contacts, but people on the sales team should not be able to see related Orders. in this scenario, Access Teams could also work, because you can disable sharing cascading on the relationship between Accounts and Orders, so sharing of Accounts with the Access Team will not grant them access to the Order entity.
   • You have two teams on an Account. One has read and write permission, the other has just read permission. You want people on the Read/Write team to have access to Opportunities, but you do NOT want the people on the Read Only team to have access to opportunities. In this scenario, Access Teams are not a great fit, because you can’t have the cascading permission apply to one group and not the other, and you don’t have the option to share the opportunities directly with the Read/Write team, because you cannot manually share records with a system created Access Team. In this scenario, an alternative solution would possibly be to use Access teams, but programmatically create an access team on the opportunity and mimic the membership of the Account Read Write Access Team, or have a process like an integration create a user created Access Team,share the Account with it, and then you will be able to also share the opportunities with it.

Access Teams are a fantastic addition to Microsoft Dynamics CRM, and they have dramatically simplified some very complex security scenarios; however, they are not the answer to every team security challenge. Knowing where they are a good fit, and where you should use other team types is crucial to success with CRM security.

by Customer Effective