PowerObjects Blog 

for Microsoft Business Applications

Making the Case for Using Access Teams in Dynamics 365

Making the Case for Using Access Teams in Dynamics 365

Today’s blogpost is intended primarily for business/technology people who are planning a CRM project and have a business model that involves either:

  • Managing teams that interact with customers
  • Having a large volume of teams and team memberships (or at least the business case for it)

In more general terms, if you have a collaborative business model where a unique set of unknown users will be required to add value to the business process – this post is for you. It’s ok if you don’t know what we mean by unknown users prior to business process completion. That’s why we’re writing the article… so, please keep reading. This article is not meant to be how-to on setting up Access Teams. Please go here to learn about implementing Access Teams. Also, Microsoft and other blogs have covered Access Teams to include all sorts of abstract technical details if you are looking for something more technical. This post simply illustrates Access Teams through real-world business examples.

If you don’t know about Access Teams, then a little bit about them (also this is a great resource). They were introduced in CRM 2013 and include added capabilities when it comes to teams and records. A very high-level overview of Access Teams:

The Entity must be enabled for Access Teams, followed by the creation of an Access Team Template that contains one or many Access Rights (User Privileges): Read, Write, Assign, Share, Append, Append To, and Delete. The Access Team Template is added to a form as a sub-grid. An Entity can have a maximum of two different Access Templates. We can develop programmatic controls automating this process to deliver solutions for very complex security requirements while leveraging out-of-the-box features.

Many of our clients are moving to new business models with highly collaborative business processes, with very complicated business rules for sharing records/data. To meet these requirements, the traditional security solutioning models need to employ a test case that considers Access Teams. You may ask why, especially since CRM is a platform on which developers can create customizations around data access that meet these requirements without using Access Teams. Well, we have seen these customizations after they’ve been built... they sound great until you try to manage or make changes to them due to business rules changing. Access Teams operate differently than traditional security roles. For instance, unlike the traditional security roles, Access Teams won't be cached because the system does not perform privilege or ownership checks (go here for more info). This is different than the traditional CRM security roles and has advantages. Conversely, Access Teams work by providing a User access to the record automatically using the privileges defined by the Access Team template for that entity type (more info here). This is good for system performance and simple to manage change and understand!

So, the above has been a lot of sizzle… now for the steak. Below are two real-world examples for employing Access Teams.

Example 1: The case for a large volume of Access Teams

This example is about managing teams that interact with customers. The source is an enterprise operating nationally and selling services using a B2C model in which leads interact with Inside and Outside Sales. The details of this example are described below:

Sales Process Information

  1. Inside Sales team receives 40K web/direct-mail/telemarketing leads weekly.
  2. Inside Sales team books appointments for Outside Sales team.
  3. Outside Salesperson gives a presentation to the lead. The company's sales process is a single presentation/appointment-close.
  4. If lead is not closed after first presentation, Outside Salesperson remains case owner; Inside Salesperson can work/follow-up/solicit.
  5. Lead is deactivated 90 days from first interaction with Inside Sales.

Business Rules

  • All leads with no booked Appointments are owned by Inside Sales.
  • Leads owned by Inside Sales are not related to a set/confined geographic region or product family.
  • Inside Sales have licenses to sell products in many states and they overlap with each other’s. Yep, it’s an ugly mess!
  • Inside Sales team members share geographic regions but do not share leads.
  • Inside Sales people only read, write, update owned leads.
  • Outside Sales work in defined geographies.
  • A lead does not change ownership from Inside Sales to Outside Sales unless and until an Appointment is booked by Inside Sales.
  • If Outside Sales do not close the sale after the first presentation, Inside Sales can follow with the lead and attempt to close.
  • Inside and Outside Sales have a 90-day window to close – the window starts with the first phone call from Inside Sales.

Solution (as a caveat, this is the Sales Access Team portion of the solution)

Because of the robust nature of the CRM security model, several different options exist here. Of course, we’re looking at an Access Team-based solution for these reasons:

  • Inside Sales was in a different Business Unit than Outside Sales, for other security reasons
  • Potentially greater than 1,000 team memberships per user (Inside Sales)
  • Inside Sales did not need to own the lead to continue working it
  • The business was looking to create an automation because the ratio of Inside Sales to Outside Sales is 1:125.

Inside Salesperson (who is also currently the lead owner) books appointment for presentation. Lead is then assigned to an Outside Salesperson. The system passes Inside Salesperson’s Username onto the Lead form, called the Lead Access Template, which has Access Rights of Read, Write, Append, and Append To. This allows the Inside Salesperson to continue working the Lead throughout the 90-day window.

  • An aside about the security model: each Inside Salesperson was in a unique CRM Business Unit to meet the security requirements.

Example 2: User must own record, variable team size, and other complex requirements

A B2B technology company sells a solution via a Partner Channel. The details of this example are described below:

High-level Overview of Opportunity Sales Process

It consists of a collaborative team from various functional units who also happen to be in different CRM Business Units. The Opportunity Sales team members depends on geography, product and deal size attributes. Many of these factors are unknown at the creation of the Opportunity record. Below is a list of functional areas the Opportunity sales Access Team may be a part of:

  1. Channel Sales
  2. Channel Marketing
  3. Engineering
  4. R&D
  5. Legal
  6. Credit

Business Rules

An Opportunity Access Team consists of CRM users determined by four geographic attributes, eight product families, and four categories of deal size and/or solution complexity. Below are additional business rules.

  • Channel Sales Manager is the Opportunity Owner.
  • Owner Teams cannot be employed on the Opportunity form.
  • Channel Sales Associates work with many Channel Sales Managers.
  • Only the record-owning Channel Sales Manager can update their Opportunity.
  • Team Members in other Functional Areas perform activities on the Opportunity form.
  • Legal and R&D members can only read the Opportunity form.
  • Marketing and Engineering can update Opportunity form.

Therefore, an Opportunity Sales Team may consist of between 6-12 CRM users collaborating on the Opportunity.


Again, because of the robust nature of the CRM security model, several different options exist here. Of course, we’re looking at an Access Team-based solution for these reasons:

  • Team members require different access rights on the record.
  • A unique set of Users will be working on a single record.
  • Creating teams automatically per records is desirable
  • Potentially greater than 1,000 team memberships per user.
  • Individual record-based access is needed.
  • Owner or the records allowed to define access to others.

The high-involvement team members like the Channel Associates, Channel Marketing Regional Lead, and Channel Marketing Manager require record Access Rights that allow Read, Write, Share, Assign, Append (links Opportunity record to other records), and Append To (if other records are linked to the Opportunity).

The low-involvement Team members like Legal, Product Family SME, R&D, and Credit require Access Rights that allow Read, Append (links Opportunity record to other records), and Append To (if other records are linked to the Opportunity).


These two examples illustrating Sales and Opportunity business processes are good candidates for employing Access Teams. If your business process requirements can be described at a high level like any of the below, we recommend considering employing an Access Team model:

  • All Team members are unknown at record creation.
  • Record owner can add additional Access Team members
  • Team Members require different access rights on the record.
  • A unique set of Users works on a single record.
  • Creating teams automatically per records is desirable.
  • You have potentially greater than 1,000 team memberships per user.

For more information, please see these excellent resources:

Happy Dynamics 365’ing!

By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

Leave a Reply

Your email address will not be published. Required fields are marked *

PowerObjects Recommends