Dynamics CRM offers an incredibly flexible security model, however it is often cumbersome to share records with colleagues or users who aren’t a member of the same business unit as the record owner. Microsoft Dynamics CRM 2013 introduced a simpler method to share records with users across different business units.

Let’s start at the beginning…Entities within Microsoft Dynamics CRM are configured to be “owned” by either a User or Team. It is also possible for records to be owned by the CRM Organisation where the notion of ownership doesn’t come into play, a user can either create or edit a record depending on the their security role.

The security model in CRM centres around the owner (team or user) of a record and the business unit or team membership that has been assigned to the CRM user who is carrying out the action within CRM. Depending on these factors determines the actions that can be carried out on a record according to the users Security Role that have been assigned to the user.

A Security Role dictates the depth that a user is able to Create, Read, Write, Delete, Append, Append to, Assign and Share. If a user has been assigned multiple security roles then the user is granted the highest permission.

The screen shot below shows the security matrix that makes up a security role within Dynamics CRM.

  • Organization (solid green circle) – This gives the user global access to all of the associated entity record within Dynamics CRM, regardless of the record owners business unit.
  • Parent: Child Business Unit (three quarter green “slice”) – Grants access to records in the users business unit and all child business units. Not shown above.
  • Business Unit (half yellow circle) – User access to records belonging to only the users business unit.
  • User (quarter yellow “slice”) – Only records that the user owns.
  • None (Red outline) – Access is not allowed for this entity.

Tip – Clicking on either the column headers or row titles toggles the security permission for the entire row or column.

A security role also includes none entity permissions which focus on other actions a user can carryout within Dynamics CRM such as  the ability to publish reports or bulk delete records.

Access Teams

So why are Access Team needed?

A CRM user can only be associated to one business unit. This therefore causes an issue when a user needs to be a member of one business unit but access records that are owned by a user or team in another business unit. Let’s look at an example…

Here is our organisations structure that has been replicated within Dynamics CRM.



Typically this works fine and the users in each business unit are able to manage their own records without any impact on the other business units. Finance users can’t see contact records that are owned by Marketing, they simply don’t appear for the users who aren’t a member of the Finance business unit. It’s as though the records are surrounded by a wall.

We can see this here…

Mike Marketing is a member of the Marketing business unit can only see marketing contacts.


Frank Finance works in finance can only see those contacts that are owned by his colleagues in the Finance business unit.

Both Mike and Frank have been assigned a new security role that called “Business Unit – Customer Service Representative” copied from the default Customer Service Representative security role. This security role has had the permissions for the contact entity changed to “Business Unit” from Organisation (see the above screen shot), this restricts the records users can read and create (write).

Imagine that our organisation is running a promotion and our Marketing and Finance departments need to work together to identify customers (contacts) that should be included in the promotion.

How can this be achieved?

Finance and Marketing users could share individual records with each other. Not ideal, there is a large overhead in sharing records both in terms of the administration of sharing the records and performance within the CRM database. Sharing uses security roles and CRM needs to create records in the Principle Object Access (POA) table. The more users and records that are shared the longer it may take for Dynamics CRM work out if a user is allowed to view or edited a shared record. Its also impossible to view the records that have been shared and the users who have permission.

We could create a team called “Promotion” and start to change the ownership of the records or create a new business unit. Definitely not a good idea, after the permission had finished the ownership would need to be change back to the original owner, which would be impossible to identify.

Using Access Teams.

The Owner of the records would remain unchanged. Access Teams allows users who are a member of other business units to read and edit records within Dynamics CRM who normally wouldn’t be able to access records within CRM.

Enable Access Teams

Each entity that will used Access Teams needed to be enabled.


Settings > Customizations > Communications & Collaboration > Access Teams.

Access Team Templates

Much like a security roles an Access Team Templates allows permissions to be assigned to each entity.


Settings > Security > Access Team Templates.

Assigning Users

The Access Team Template doesn’t include the members that we would like to view or edit contact records. This is detailed in the next two steps which is a little strange and isn’t very obvious.

Edit the Contact form and add a Sub-Grid.

Settings > Customizations > Contact > Forms > Select the Contact Form. Use the toolbar choose select Inset > Sub-Grid.

Set the sub-grid properties, including the Data Source.

  • Records – All Record Types
  • Entity – Users
  • Default View – Associated Record Team Members
  • Team Templates – Marketing & Finance

Save and Publish the form.

Granting Access

Granting access to a record using Access Team requires a user with edit permission opens the record and add users or teams into the sub-grid on the contact form.

Here we can see that Mark, a user in the marketing business unit has added Frank Finance into the sub-grid on the contact form.

Now when Frank looks for contact records in Dynamics CRM he will see the contacts that he saw before and also Mike Marketing record.

Frank has been granted the permissions that where specified with the Access Team Template.

Behind the senses Dynamics CRM creates a team when the first used is added into the Access Team sub-grid to control access to the CRM records. This allows a simple advanced find query to be used to identify the records that have been shared via Access Team. This isn’t possible when using standard sharing and would require a SQL query to be written, which isn’t possible with CRM Online.

CRM Magic