Sonoma Partners Microsoft CRM and Salesforce Blog

Access Teams: One developer’s journey of hunting down his white whale and living to tell the tale

Today's post is written by Mike Dearing, a development principal here at Sonoma Partners.

Since the introduction of Access Teams in CRM 2013, I’ve had several opportunities to implement creative ways of leveraging this leaner form of record sharing to address our client’s more advanced security needs.  For those unfamiliar with this feature, it is a simplified and higher performing alternative to the days of sharing records to individual users with no relation to one another other than for the purposes of accessing a particular record. 

MSDN has a great write up if you want to learn more about when to use access teams versus owner teams.  Though implementing and using access teams is fairly straight forward, I recently ran into some snags when programmatically adding members to these teams that’d I’d like to share with my fellow CRM developers to hopefully save you the headache of troubleshooting these should you be as unfortunate as I once was.

The user id is invalid

What user id, you ask?  After some sleuthing, I determined it to be the team administrator being added as CRM programmatically created my access team.  If you find yourself programmatically adding members to access teams, make sure that you are not instantiating the organization service, or that a prior plugin that kicks off your code isn't instantiating your organization service, as SYSTEM. 

The initial access team creation, which happens when the first member is added to it, needs to run as an actual CRM user.  Whether or not you leave that as the current user, or if you decide to elevate to a system administrator service account, is up to you.  That user then becomes the team administrator for the access team, which CRM prevents from being SYSTEM.  You will get an error of "the user id is invalid" otherwise.

The wrong way (UserId will be SYSTEM):


The right way (ensure UserId is not SYSTEM):


Everything the light touches is our kingdom

The cascading section of this post has been updated to include a leaner cascading configuration, thanks to clarifications from Adam Vero.

If you want child records to inherit their parent record’s access team privileges, you will need to set up the behavior for the child relationship to have, at a minimum, cascade share, cascade unshare, and cascade reparent. Cascade share and unshare ensures that any child records created before your access team has its first member added will inherit the parent's access team template's rights appropriately. Cascade reparent will ensure that any records created after the access team has been added (or switches parents from a different contact to the one with the access team) will also inherit these rights. 



That’s it for now, my friends.  May your future programmatic access team implementations be merry and bright!

Facing your own CRM white whale? Contact Sonoma Partners, we’d love to help out!

Dynabacus the Microsoft Dynamics CRM Record Count Tool


Topics: CRM Best Practices CRM for Professional Services Microsoft Dynamics CRM 2013