A new feature in CRM 2013 is Access Teams. For those people studying for the MB2-703 – CRM 2013 customization and configuration exam, you will need to know the difference between access teams and Owner teams.
I personally have not understood the real benefit of Access teams and access team templates, I understood it was an quick way to share individual records but I wasn’t sure how this was different to the current sharing functionality.
First I will go through the Access Teams functionality and then we will focus on the differences
I will also mention Microsoft have a very good white paper on Access Teams which you can download by going to the link below
Before I went through sharing and teams in the previous blog\video which you can see using the links below go through more tradition teams and sharing
Blog – CRM 2013 – MB2 703 – Manage user access, Teams and sharing
video – CRM 2013 – MB2 703 – Manage user access, Teams and sharing
Access Teams And Access Team Template Demo can be seen in the video below
The standard owner team/user functionality allows you to share records and components (views, dashboards) to users or owner teams.
This functionality is very useful but the sharing process is not very visible and can be difficult to manage. Sharing records is done by an individual user and the only way to see what records are shared and to whom is by going to the record/component and clicking the sharing button
Access Teams and Access team templates are a method to share permissions and records, which is easier to manage, quicker to add/remove users/teams because Access team templates will applying a standard set of privileges (read, write, delete, append, append to) rather than having to set this up for each individual user/team.
An overhead of Owner Teams and sharing is they write records to the POA (Principal Object Access) table and this may eventually can result in performance overhead. It should be noted that sharing records with teams is a lot more efficient than sharing records with individual users because it only writes less records to the POA table (for the team) rather than each individual user.
Enable the entity
Access Team templates are enabled on an entity basis and you have to enable Access Teams on the entity in the communications and collaboration as you can see below on the screen shot.
Once you have ticked the access teams check box, save and publish (I don’t think you have to publish but just to make sure).
Create your Access Team
Go to SETTINGS –> Administration –> Access Team Templates
Click the New button
You now have to create you team name, specify the entity the Access Team will work on and the access rights
Now the next step is not straight forward, when I say that I don’t mean it’s difficult but I do mean most people would never guess what to do next.
Add the Access Team sub grid to the form
You need to customize the form of the entity you want to add the Access Team Template to and in my case it’s the account form
You need to add a sub grid to the form
Records – All Types
Entity – Users
Default View – Associated Record Team Members
Team Template – Hosk Account Access Team – this is the team template I created in the step before, yours is probably called something different.
save and publish the changes
now you can go to account records and there will be a sub grid which will allow you to add users to it. These users
Odd things happen when you add a user to the user grid it will automatically create an Access Team but the odd things is you can’t view this team in the Teams section in Administration even if you select All Teams or Access Teams.
The only way to view the teams is to create an advanced find, search for Teams and choose of type Access.
You will then see some odd teams with Guid names
if you click on one you can then view the details. So you will get a new team for each entity and access template type.
To help identify the different teams you can put something in the description
You can also add and remove members in this screen. If you remove all members the team will disappear until you add another user to it.
Facts and stats about Access Teams, the bits below are useful for those study MB2-703
- You can more than one Access Team template for each entity
- The default number of access teams templates for each entity is two
- The number of access team templates you can have for each entity is controlled by the MaxAutoCreatedAccessTeamsPerEntity deployment setting.
- MaxEntitiesEnabledForAutoCreatedAccessTeams deployment setting has a default value of 5. This controls the number of entities it’s possible to enable for auto-created access teams.
- You can change the MaxEntitiesEnabledForAutoCreatedAccessTeams , MaxAutoCreatedAccessTeamsPerEntity only on Premise installations and you cannot edit them for Online.
- A system generated Access Team isn’t created for each record until you add a user to the sub grid on the entity.
- if you delete the team, this is the same removing all the members in the sub grid on the record.
- if you change the access rights on Team Template this will only change the access right to new entity records/access teams. Any records already created will use the previous set of privileges.
- Access teams with Share access right ticked will mean any user who is in access team will be able to add (share) others to the access team for that record.
- Users cannot grant privileges they do not have. So a user can only add new members to an access team where the access team template has create privilege only if that user has the create privilege for the entity.
- Access Teams created automatically by adding users to them are not shown in the system team views
- Access Teams created automatically can be seen by doing an advanced find and select Team Type = access
- Access Team created automatically have the is system managed field set to true
- Access Teams can be un ticked on an entity (unlike Queues)
- If you want to delete a Access Team Template you will need to remove all the sub grids using that specific Access Team Template before you can delete it.
Access teams don’t user the POA table
The final import thing about access team is they do not write to the POA (Principal Object Access table). This table holds all the rules about sharing for users/teams for each entity. The POV table holds information about sharing and security/access and is read every time a user accesses a record to make sure they have privileges to view and then update/delete it. A big POA table with lots of sharing of records can in some cases slow down the system.
After reading CRM MVP Adam Vero’s comments it seems access teams do write to the POA table so this isn’t where the advantage of Access teams comes from. On the efficiency side Teams do write fewer records to the POA table than sharing to individual users.
Owner teams are good when you want to share records to teams and those teams should have their privileges set by security roles.
access teams are good for quick ad hoc sharing of records where the users who will need to use a record may change often. Access teams allow you to quickly add and remove users.
Reading the White paper it has a good summary of the key features
- As teams in Microsoft Dynamics CRM with security roles
- Can own records
- Privileges are granted by security roles and change dynamically as the role definition changes
- Needs to be manually or programmatically created and managed
- Will be cached in CRM Server when a user accesses the application
- Can act as resource in service scheduling
- Can’t be granted security roles
- Can’t own records
- Accesses records through sharing
- Sharing privileges are defined by an access team template but don’t change dynamically for existing records if the template changes
- Won’t be displayed in most team views
- Can be system managed, directly from the form of the record that it relates to
- Won’t be cached because it doesn’t derive privilege or ownership checks
- Can’t be scheduled as a resource in Service Scheduling
- Not shown in team views as typically used at high volumes
As always, a couple of points, some minor, some major:
You say “Users cannot grant privileges they do not have. So a user can only add new members to an access team where the access team template has create privilege only if that user has the create privilege for the entity.”
The first bit is true, and is always a useful reminder of security 101. But “create” is not a privilege you can share – shares apply to records, which by definition are already created. Substitute a different privilege in your example, such as delete.
Also note that to add someone to an Access Team, you must have the rights to share the record. You might already have these rights through your security roles (perhaps a manager can share any record in their Business Unit), or, as you mention, because they have been granted sharing permissions when they were added to the team themselves. This model, which is mentioned in the course, I think of as a “collaborative” one – anyone in the team can invite people in, but you cannot necessarily add yourself and just “opt in” to deal with a record.
Principal Object Access = POA, not POV (=point of view, and short name for POVRAY, a great ray-tracing programme from the 90’s)
To be clear, there is one Access Team per record per template that has users added. So if I have two templates for the Opportunity entity (maybe giving read, and read-write privileges), then there could be zero, one or two teams for every record. Each Access Team name is a *concatenation* of the GUID of the template and the related record, just to keep them unique.
In the video you mention a couple of times that it seems weird that Access Teams are not shown in the system views of Teams. This is simply because they are explicitly filtered out. You can change the definition of those views, or add your own to show them if you want to. I could imagine doing this for Teams of type “Access” which are *not* system managed, in particular.
It is not really weird if you think about a global organisation with thousands of records which use Access Teams for sharing – you would never find the teams you really want to manage amongst all of the access teams. Since you should not need to directly administer access teams in the same way, you might as well hide them.
IMPORTANT: Records shared with Access Teams DO write to the POA table, in order to describe the rights that have been shared with the Team for a given record (easy to prove by taking a look in SQL). So for every Opportunity that has users added to an Access Team, there is a Team record created and the Opp is shared with that Team. This could involve thousands of POA table rows, so this is not where the performance improvements come from.
You say “Owner teams are good when you want to share records to teams and those teams should have their privileges set by security roles.”
When you share a record with a Team, the members of the Team get the privileges explicitly defined in the share, regardless of security roles the Team may or may not have. The rights shared will only take effect if the user also has that privilege to at least User level (so you cannot share a record with someone and give them more rights than they would have if they owned it).
Your article and video do a good job of showing *how* to use Access Teams, I’ll try to write one on *why* you would want to in the first place, and try to cover off that elusive performance improvement…
I appreciate you detailed post, it was very interesting. One day I learn how access teams and templates work in the front end and today thanks to your comments I am learning more about how they work on the back end.
POV, I don’t know why I put that
Access Teams not in views
I guess it makes sense in some ways they aren’t in views because they are dynamic, quick and have incomprehensible guid names but then on the other hand it would be useful because you can still use the view to manage the members. As you say there could be 1000 of access teams created which is probably why they make it so easy to manage the user access with sub grids.
I guess this is part of the process of understanding new functionality and how it works.
thanks again for your very informed comment, it certainly made me think a great deal about Access Teams and what I wrote.
Once again you have proved why you have the title of CRM Master
I’ve written up some thoughts about why you might want to use Access Teams in Dynamics CRM 2013, and a brief look at how they can improve performance: http://blog.crmguru.co.uk/2014/05/16/why-use-access-teams-in-dynamics-crm-2013/
Amazing article, I will feature that in next weeks CRM articles of the week and a very good chance of being article of the week (and there is no accolade higher than that!!)
Thanks for clearing up access teams for me
really helpful post!!
Fantastic Explianation , Thanks very much for gathering all key information on this topic.