Background

There’s more to the concept of Team Ownership in Microsoft Dynamics CRM than you may originally think, which means you’ll want to give that topic significant consideration and understanding before embarking on a security model that utilizes team permissions or team ownership. In releases prior to 2011, the concept of Teams existed but Teams were simply groupings of users. Their primary function was to allow the sharing of records and/or views with multiple people in a bulk fashion rather than having to share records one by one. Since version 2011, a Team can actually own its own records, and can have its own security role(s), giving CRM architects more options for building more complex security schemes.

The security model in CRM makes it very easy to create permissions for users in the same Business Unit (BU) to see and collaborate on each others records. You simply give users BU scope to the entity and privilege(s) in question, such as a Contact’s read and update privileges.

For example, a security role with BU scope on Contacts for read and update will let anyone with this role update all of the contacts in one’s own BU (meaning the Contact Owner belongs to the same BU as the user). No need to create a team here to improve access and collaboration. Starting in CRM 2011, you can create Teams to allow for collaboration on records “among users of different BUs” that couldn’t be solved with the permissions available in the previous security model.

Without Teams, the only way to let people in sibling BUs share/collaborate on records is to give the users “Organization” level permissions, which means access to all records in all BUs which is not usually desirable.

Record Access Implications

An individual CRM user has permissions that are accumulated across all security roles to which they are assigned; and accumulated across all inherited security roles based on the Team(s) on which they are Members. So if a User has a personal security role that doesn’t provide the permission to read accounts, but this same User belongs to a Team with a security role that DOES have the Account read permission, then the User will be allowed to read accounts. In other words, the privileges are additive across user security roles and inherited team-based security roles.

User Scope on Team Security Role

When you create a security role for a Team, and set one (or more) specific permissions at the “user” scope level, this means the CRM User inheriting this permission via membership on the Team WILL ONLY be granted this permission on records OWNED by the Team – not on records owned by a user on the Team. Assume we have a partial BU hierarchy as depicted in the image at right. Now, imagine Jamie and Earl being CRM users with only “user” update privileges for the Contact entity. If Jamie and Earl are on a CRM Team called “Advisors” and the Advisors team has “user” privileges to update Contacts, then both Jamie and Earl will be able to update their own contacts, and any contacts where the owner is the Advisors team. They WILL NOT have the privilege of updating each other’s contacts. In CRM 2011, if your Team owns a record, then you inherit the permissions assigned to the Team, because you are a member of the Team, but ONLY for those records that are owned by the Team. Hence, if you want team members to share permissions on all records owned by individual team members, you will need to use a higher scope level than “User” on the Team’s permissions (i.e. on specific Security Roles created for the Team).

Business Unit Scope on Team Security Role

When you assign a team permission at the BU scope level, this means the user’s privileges will include all of the records of that type that are owned by users in the BU to which the team belongs. For example, assume the Advisors team is part of the Consultants Unlimited (aka CU) Business Unit and the Advisors team has a security role with contact update permissions of BU scope. And assume Earl and Jamie are in the Associate Advisors (aka AA) Business Unit, but they are still members of the Advisors team. Both Earl and Jamie will inherit the permissions of the Advisors team, therefore they will be able to update contacts owned by any user in the CU Business Unit, along with any contact owned by the Advisors team.

This brings up a point in which the team architecture still leaves something to be desired. Suppose you wanted to give Earl and Jamie privileges to update contacts owned by either Advisors or Associate Advisors. You would need to create 2 teams, one that resides in each of those Business Units, and make Earl and Jamie members of both teams.

Insight: it would have been great to have the ability to assign security roles from different BUs to the one team, so that one team could have a security role from Advisors with BU privileges, and also a security role from Associate Advisors with BU privileges, which would give the team members “all” privileges from the security roles of both BUs, but this isn’t possible in CRM 2011. A team can only have security roles from the BU in which it resides. Starting in CRM 2013 there is a new concept of “Access Teams” which may solve this dilemma.

Parent:Child Business Unit Scope on Team Security Role

This one requires some explaining up front for those who aren’t familiar with what this privilege means, since its name is anything but intuitive. This privilege level grants a user access to any records in the BU in which he resides, and those in any BU below it. For example, if a user in the Consultants Unlimited BU had Parent:Child BU privileges to read contacts, he could see the contacts owned by:

· any user of the Consultants Unlimited BU

· any user of the Advisors BU

· any user of the Associate Advisors BU

· any user of Adv Farm 1 or Adv Farm 2 BUs

If a CRM Team has this privilege level, it grants the specified privileges from the security role to records owned by any user of the BU that owns the CRM Team, and to any records owned by users of child BUs. For example, if the Associate Advisors team were to be assigned to the Advisors BU, and if the team’s security role had Parent:Child BU privileges to read accounts, then Earl and Jamie could read accounts owned by:

· any user of the Advisors BU

· any user of the Adv Farm 1 or Adv Farm 2 BUs

Which brings us to the final points about data access: Using Views.

Using Views

Question: what views can a user go to in order to see the records to which he has access by virtue of his team membership?

Answer: any view that will logically contain those records.

However, keep this in mind: these records WILL NOT show up in “My Active <entity>” view. The reason being…the filter of the My view is literally based on the owner of the record being the “current user”, not other users that belong to the same BU or Team. However, the current user WOULD see those records in the “Active <entity>” view, and in any other view which doesn’t logically filter them out.

Note: starting in CRM 2011 there are My Team’s <entity>” type views in the default solution. We recommend that you investigate how the Team views will render the records to different users of the Team or the BU before rolling out a new team-based security scheme.

Team Permissions Can Affect More Than Record Access

The fact that a Team has a Security Role means that the implications of team membership now go beyond record access. For example, if we create a Team with the System Administrator Security Role, then everyone in the team can do anything they want – see all the records in every BU in the system, but also make customization and configuration changes, change security roles of users, etc.

Teams can also be used to minimize the work required to change security roles frequently, if a company has such a requirement. If a set of permissions needs to be granted and removed from users on a periodic basis (which could even involve more than one security role), the role(s) can be granted to a team, and the users can be added to and removed from the team more quickly than the role could be granted directly to the users. It’s also easier to check and see who’s in a team than it is to see who has what role.

Appendix:

Blogs that may provide more insights:

http://piers7.blogspot.com/2011/05/permissions-issues-in-dynamics-crm-2011.html

A visual example:

Suppose this was a user's original security role…

 

And suppose this will be a new Team-based security role that each user on the team will inherit to receive a higher set of permissions as listed below:

 

Note: Permissions need to be at BU level or above to get privileges on records owned by users within the BU. If permission is at User level, then only records owned by the Team will receive the higher level of permission. Make changes to User and Team security roles as shown in the pix below:

 

So in this scenario, Chris will now be able to Create and Update account records owned by any member of the LU DEV team since he is part of that team and he inherits the BU level privileges of that team’s security roles. If Chris were removed from the LU Dev team, then he would no longer be able to create or update any accounts, because the default limited role would be his only security privileges at that point.

Summary/Conclusion:

The CRM Security model is broad and deep. It takes a bit of time to wrap your head around how it works and all of the different options you have.

When user count is relatively low (say 200 users or less), it may not be worth the complexity of implementing team-based security.

When user counts start to get in the 250 – 500 range, or if your security requirements really do fit a team-based model, that is all users of a team always have the same permissions, then it is worth spending time in your Development and Testing orgs creating team-based security schemes and predicting your maintenance and upkeep time of user-based security versus team-based security.

We hope this article has been helpful to point out the features, challenges, and pitfalls of moving to a team-based security model. For more information on this blog or C5 Insight, contact us here!