CRM 2013 New Features: Access Teams

The latest release of Microsoft Dynamics CRM comes with a new security model approach for us to consider.  The new “Access Teams” functionality in CRM 2013 suits scenarios where data access rules cannot be easily determined upfront but rather need to be set ‘on the fly’ on a record by record basis.  The common example is where an organization assembles a unique group on individuals for each sales pursuit or to manage each customer.

In this post I will explain the advantages of this new approach over the old approaches we had in CRM 2011 and I will demonstrate how to configure Access Teams.  But first let me show you what this looks like…

Once Access Teams are configured for an entity, you will have a sub-grid on your CRM form from which you can simply pick and choose who to grant access to:


And that’s it, that’s all you need to do as an end user.   Whoever  you select will immediately be granted access to the record and (potentially) to its child records.

How is this achieved?  Well, behind the scenes as soon as you add someone via this sub-grid CRM will create an Access Team, add the user to the Team and then share the record to the Team.  

So there is not a lot of new magic here, this is just Team-sharing automation, but now available out of the box.   

Do note though, these new Access Teams are treated a little differently from the traditional Teams we know and love in CRM.  They are stored in the same entity but CRM treats them differently to optimize performance (note: CRM filter Access Teams out of views by default, you have to use Advanced find to see them, they will stand out when you do see them as they are named with a GUID).  Traditional record-owning Teams are cached by CRM and when you have users belonging to a large number of Teams you can suffer from performance problems.  These new Access Teams are not cached and that avoids this performance limitation.   However, because behind the scenes this functionality is using Sharing you are vulnerable to the performance issues associated with blowing out the Principal Object Access (POA) table.  Make sure you read this whitepaper a few times.  You also need to consider child records and whether the share will cascade or not (more detail here).  Not cascading will result in records not being visible, cascading will result in more POA records. 

Alternative Approaches

Users can create a Team, add members to the Team and assign the Team as the owner of the record.  Setting this up each time is a clunky user experience.  You lose the distinction of a primary owner and this will result in poor performance once a user belongs to too many teams.  On the plus side there is minimal POA impact.  Do consider though, do you still want a specific individual identified as the Owner of the record (perhaps with additional permissions) or is it ok to just have a Team specified?   You could always put a custom User lookup field on the form if calling out an individual owner was important.

Alternatively, you could stick with one record owner and have users manually Share to grant permissions out to individuals.  Again the user experience with setting this up each time is clunky and with this approach you can also hit performance problems if dealing with larger volumes due to the number of sharing records generated in the POA table. 

Setting up Access Teams

The configuration of Access Teams requires a little ‘self-assembly’.  There are 3 keys steps:

1. Enable Access Teams on the entity:


2. Configure a Template:


The template is what defines what permissions the Access Team members receive:


3. Add a “Users” sub-grid to the form via the configuration options shown below (you need to get this exactly right):



Using Multiple Templates

If you would like to use Access Teams but want to say grant some team members full access and others read-only access you can achieve this with multiple templates and multiple sub-grids. e.g:

I define a new template:


And then reference it on a second sub-grid:


And that gives me this:



Now, if you are trying this out and your sub-grid is not working right – perhaps its displaying unrelated users – try removing the sub-grid, publish the change and then re-add the sub-grid, making sure you set the Default View and and Team Template correctly:


I have found that if you set these wrong initially the sub-grid breaks and correcting the values doesn’t solve the problem, you need to recreate the sub-grid.


So, is this is a good feature?  Should you use it? 

If you aren’t dealing with large record volumes (e.g. hundreds of thousands or millions of records) then sure, consider it, but test the cascading behavior carefully to make sure team members get all the access to child records you expect.  Look out especially for non-parental relationships, they may give you grief. 

If you are dealing with large record volumes you need to use this approach with caution, just like you do when considering any large scale use of Teams and/or Sharing.  Microsoft have done their best to mitigate performance issues with this approach but its still vulnerable to POA explosion.  Your life is going to be a lot easier if you can get by with a Business Unit security model.  If it was my choice and I was not influenced by regulatory requirements a Business Units design would always be my approach.  Too often CRM customers have an unjustified need to lock down data access and it just causes unnecessary problems. So if you are a customer, re-think your requirements.  If you are a Consultant, push back, test the requirement.

11 thoughts on “CRM 2013 New Features: Access Teams

  1. Jukka Niiranen

    One issue I’ve ran into with the Access Teams and cascading sharing is that the behavior appears to be different for default entities vs. custom entities. For example, using an Access Team on the account record, when adding a user to the team he will gain access to all the related opportunities, quotes etc. However, with a custom child entity related to the account through an exact the same kind of 1:N relationship configuration, the user will not see records that have been created BEFORE he was a member of the team. If you then later on remove the team membership and add it back again, the rights gained during the previous team membership do remain there, meaning the user can always see the records created after the first time he has been a member of the account team. Some strange behavior here that I haven’t gotten my head around yet, but it’s something to be aware of if you plan to use CRM 2013 Access Teams for scenarios where sharing custom child entities is required.

    Another gotcha to be aware of is that the Access Team Templates are not solution aware. This means that if you create a new template for the account entity, for example, then include this as a subgrid on the account form and export your solution from dev to test environment with the account entity, the Access Team subgrid on the account form will be broken, as the Access Team Template that the subgrid is referencing does not exist. You’ll need to create the template manually in each environment, but I’m not sure how you could preserve the reference to that template across different environments with unique GUIDs while moving the account forms from one environment to another.

    Aside from these few initial bugs, I do see the Access Team feature covering a lot more real life business scenarios than team ownership, so it is a very welcome addition to the Dynamics CRM feature set.

  2. Rana Potter

    How do you control who can add members to an access team? Once a user has Write capabilities to lets say the Account record, is there any way to keep them from adding users to the Access Team?

  3. Evelyn

    can I send email to the Access Team?
    e.g. I have created Access Team sub-grid in the Case form.
    Then, in the case record, added users to the Access Team. Can I specify standard workflow to send email to those in the Access Team on trigger onChange/onAssign/onResolved etc.?

  4. John

    I realize that the actual teams and templates are not solution aware but I’m also finding that the configuration of the entity to have access teams is also not coming across with solutions. Is this a bug or am I missing something?

  5. Pingback: MS CRM 2013 Erişim Takımları(Access Teams) nedir? Nasıl kullanılır? | Crm Dersleri

  6. Ben

    Quite interesting article but it seems I cannot achieve exactly what I want with that feature:
    When a person is added to the Opportunity sales team, all of the child quotes should be shared as well.

    It seems its not possible since the relationship is a system one and repaent and sharing attributes are set to none… Or is there a way around?

    Thanks in advance,

  7. Deep

    Nice article. I think we cannot use this feature to filter team based records in lookups, we have to use either share or filtered lookup. Please let me know If I am wrong.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s