The desire to share access to records has long been a requirement CRM systems. When an account manager can share a record with a selective group of people that make up the account team for an account, it allows an organization to connect specific resources with specific customers as the customers make their way through the relationship with an organization. In an integrated CRM system this sharing and access is often driven programmatically. That enables the specific people who work with the customer directly in non-CRM systems, let’s say invoicing, to have access to that customer’s record in the CRM system.
In this article I will detail how to manage this in the current Dynamics CRM 2013. First, a bit of background because this is technically much more complex than one would imagine. In past versions of Dynamics CRM this was accomplished via a mechanism called Sharing. It actually was a bit of an Achilles heel for CRM in that it propagated security records for each of the children entities that fell into the scope of the share. So an Account record that had 10 Contacts with a 100 emails each shared to 20 users would propagate 40,000 permission records. Needless to say this method did not scale well across a large system. As soon the permission portion of the databases became the largest part of the CRM internal database with millions of records.
Dynamics CRM 2013 fixed this problem by using a method called Access Teams. Enabling this configuration generates a single Access team record, and users are added to this Access Team via a Team Membership records. So instead of the 40,000 database records in the case mentioned above only 21 records are added, and the Database Administrators rejoiced. So to add a user to the access team, one needs to create a Team Membership record. This entity shows up on the Scribe entity browser. One can see that only 2 fields are need to be mapped, so how hard could this be? Well it turns out that it is actually pretty complicated.
The trick on this is trying to find the Team ID. It should be noted here that the team ID is generated by the System when the Team is created. One cannot create the Team directly. If attempted via Scribe, the CRM platform will return an error indicating that Access Teams can only be created by the SYSTEM. So one can’t create it and then pull a Target Variable. Bummer. This means that the Team Entity specific for this Account record needs to be found. This Entity Relationship Diagram (ERD) shows the connections between the elements involved here. To build a Workbench file to add users to this Access Team the following 3 steps are required.
1. Build a lookup on Account ID & TeamType=1 to find the Account Access Team ID: 2. Build a Target Variable on the TeamID for the Team that is found. 2.5.We also need the SystemUserID for the Users that need to be added to the Access Team. So that will need to come from another Seek operation, or maybe it is in the source.