In this post, we explore why government organizations can benefit from a one true connected enterprise solution.
Today’s blogpost is intended primarily for business/technology people who are planning a CRM project and have a business model that involves either:
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.
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
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 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.
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:
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.
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:
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:
For more information, please see these excellent resources:
Happy Dynamics 365’ing!