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.