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
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