Why Use Access Teams in Dynamics CRM 2013
May 16, 2014 10 Comments
It seems to be “Access Teams Week”.
Larry Lentz wrote an article CRM 2013 Access Teams in a Nutshell which is a great introduction to what Access Teams are and what they do. Ben Hosking wrote a post in his series about preparing for the CRM Customization exam MB2-703: Access Teams and Access Team Templates how to use them and key facts.
Both of these are really good primers on the mechanics of using Access Teams but I think they miss addressing one really big question – why would you want to use Access Teams in the first place?
I think there are several reasons to use Access Team Templates, some in terms of usability, others from a more technical or performance perspective, and some cases for using manually-created Access Teams.
Don’t forget – any type of sharing should be for exceptional circumstances, for parts of your security requirements that cannot be addressed with other parts of the security model. I recommend removing the Share privilege in all security roles, for all entities that do not have an explicit reason to need users to share them. This removes the temptation to use it unnecessarily, and simplifies the user interface further by removing one more button.
Avoiding administration overhead
In the old sharing model, you either had records explicitly shared with users (leading to a huge POA table), or with Teams (not quite so bad). Either way this is pretty inefficient, and there
Sharing with Teams was slightly better than with individual Users, but this assumes that you have lots of records that need to be shared with the same sets of users, with the same rights. When this is not the case (which is very often) you would end up with loads of Teams and the administration of these, adding or removing users, becomes a huge overhead.
Access Teams give lots more flexibility in sharing any given record with any random set of users, and because the team itself is created and maintained by the user interacting with the shared record , there is no overhead for a central administrator looking after all the team memberships.
Give control, but keep control
Because Access Teams are managed directly on a record, they give control to users to choose who can work on a record, and they can add them to the most appropriate team if you have more than one template for the entity.
At the same time, the system customiser or administrator controls what rights the users are giving away. This prevents users giving away loads of rights without considering the implications, makes sure the users they share records with get all the rights that they need, and all with far less effort on the part of the users.
As an aside, remember that users must have share privileges to a record to be able to add other users to an Access Team for the record. So because they still have share privileges, they could use the old method to share the record in an uncontrolled, unstructured way. Hopefully the new method would be so much easier that would not want to, but to avoid the possibility, you could remove the buttons from the command bar using the excellent and free Ribbon Workbench tool from MVP Scott Durow.
Queries and reporting
With sharing in previous versions of Dynamics CRM there was no way to query or report on shares from the user interface, for example to show all the records that had been shared with a particular user, or to show which users a record had been shared with. The only way to see what shares were in place was to open a record and click to open the sharing dialog box – one at a a time. There is no way to get at the POA table from within the interface – and with CRM Online you can’t even go ‘round the back’ to the SQL Server.
Because the Access Team model uses real teams that actually contain users, and Access Teams are associated with templates, you can build views such as "All <records of some entity> shared with <Current User>". In some scenarios, no user will ever own records, and will only work with records explicitly shared with them, so these kind of views are essential. If you need to check up on who has access to particular privileges such as “All Users who are in any Team which uses the template called ‘Opportunity Assign+Delete’”
One of the reasons that you will hear for using Access Teams is that they will improve performance compared to ‘normal’ sharing. But getting to the bottom of why, and how big an impact this can have, can be a little more difficult – reading some articles it sounds like it is just “magically” better. So first we need to look at when and how sharing impacts on the performance of your CRM system – and when it doesn’t.
The best document to read to properly understand how all the different aspects of Dynamics CRM security work is the white paper Scalable Security Modelling with Microsoft Dynamics CRM 2013. There are several points raised in this document that are particularly relevant to looking at the performance impact of your security design with regard to sharing:
- In general, performance is most relevant when users interact with views (or any other feature that does a “retrieve multiple”) to get many records at once. The platform must evaluate the query and then filter this to only include records the user has read access to. Other privileges are not relevant at this point.
- When a user selects a single record, the security model needs to be evaluated again to present the correct interface such as command bar buttons or displaying a record form in read-only mode. But this is far simpler because all the queries will be looking to match this single record, rather than combining two large result sets.
- The platform first tries to find out if the user has global (organization) level read access to the entity in their own security roles, and then in any roles assigned to all the Teams the user is a member of. If they do have global read access, no further checks are needed – so the POA table will not be queried, and the size of it has no impact. So making sure users have global read access to an entity is a great performance benefit. Don’t forget this might mean you can give global access to lots of entities that everyone uses all the time, reducing the impact on the system for those entities, and leaving more performance for entities where your security model needs to be more complex.
- In order to improve performance, the CRM web server caches various things, including the list of security roles assigned to each User and Team, and a list of the Team’s a user is a member of. If a User’s Team memberships change at all, the cache is invalidated and must be reloaded by querying the SQL server next time the user tries to perform any action. So in the old model of sharing records with Teams, and then adding and removing Users from these Teams, this would frequently invalidate the cache (perhaps dozens or hundreds of times a day), meaning more work to be done every time. Because Access Teams cannot have security roles, they are ignored and are not included in this cache so the cache remains valid longer even though a user may join or leave many Access Teams during a day. Access Team membership will only be relevant when assessing shares, not during the initial checks for security privileges.
- If a User is a member of a large number of Teams in CRM 2011, especially from different Business Units, then this becomes more complex for the platform to evaluate and figure out the effective permissions the user has – even if the Teams are all assigned to the same (inherited) roles. This is not just a case of adding them all together and “inheriting” the privileges from the Teams, as I discussed in my article Security Roles and Teams in CRM 2011 – An Inconvenient Half-Truth. In 2013 this is still the case for Owner Teams, but since Access Teams can never have security roles they can simply be excluded from this calculation. So a combination of reducing the number of teams to consider in the security evaluation, and ensuring the CRM server cache remains valid for longer will contribute to better performance using Access Teams in CRM 2013 than sharing in CRM 2011. The gain will be more noticeable in very large organisations with many records that are secured using sharing as the primary access model (you see no records that are not explicitly shared with you).
What about manually created Access Teams?
I have been asked a few times why you would ever want to use manually created Access Teams. It makes good sense to consider using a manual Access Team where you might otherwise have used an Owner team for something other than security. For example, for Case escalation – if a user is a member of Team X, escalate overdue Cases to User Y. Or to filter views or reports, especially for constructions like “All records owned by any User in any Team I am also a member of” (=my colleague’s records) or “All records owned by any User in any Team of which I am the manager” (=my reports’ records). In these cases, it is simply the membership that matters, and the Teams will never have any security roles.
So don’t overcomplicate the security model with Teams that do not need to be evaluated, and don’t risk invalidating the cache every time the membership of these Teams changes – use an Access Team.
You might also use manually created Access Teams for records to be shared with using the “old” way of record sharing. If the membership of the Team will be the same across many records, and will not change very frequently, you may not need the convenience of showing this in a sub-grid on the form. For example, you might have a data quality team, and need to be able to share selected records with this Team. You don’t want users to have to add the correct staff every time, it should be a binary decision – do I need to share this record with the data quality team or not. If they do share the record, it will be available to all the members of the Team, which is centrally maintained.
Find out more with training from CRM Masters
If you want to find out more about Access Teams, when and how they improve performance and indeed all aspects of Security Roles, Teams, sharing and the interactions of the whole lot, you should consider our CRM Masters training course Microsoft Dynamics CRM Security in Depth.