In my last post, I reviewed the pros and cons of the System User Ownership model. Now we’ll review a second approach, Team Ownership.
Approach 2: Teams
The easiest way to think of Dynamics CRM Team Ownership is to look at how the Windows operating system uses security groups. In the Windows platform, a permitted user can create a security group that can be given permissions to files, shares, and roles on a computer. There are groups that are created by default, and an administrator can modify, create, or delete these security groups to fit their organization. Any user added to a security group automatically inherits the permissions of that security group, augmenting any permissions that they have on their own user account. Using security groups provides the system administrator with a manageable method of granting permissions to users without having to redefine the permission attributes each time (i.e. all file shares, all computer directories and files, and all permissions within Local Policy).
This is great, but what does this look like in Dynamics CRM 2011?
The same conveniences are possible for a system administrator when managing access to records using teams within a single business unit. As a system administrator, you’ve made the decision to administer permissions by grouping people into teams organized by functional roles, with the permissions contained by the security roles assigned to their Dynamics CRM team. Dynamics CRM records can be assigned to teams, providing all members of that team ownership access to that record. Since users can belong to multiple teams, it is even possible to extend a user’s function role through multiple team membership and giving them access to more records.
I like to think of sales teams for this model. My scenario describes a company that uses a team approach to selling their company’s products. The sales team is divided into multiple territories (let’s say states of the U.S.), and the team structure consists of an account manager, technical sales specialist, support specialist, customization architect, and contract specialist. Our team will be called the Washington State Sales Team, with one person from each role above. When a sale is in progress, the opportunity is assigned to the team, granting equal visibility across all team members. Instead of transferring ownership to each team member along the way, each member will have tasks assigned specific to their sales process but tied to the opportunity.
What works in this approach:
- Functional Team Organization: Within organizations, there are projects or account management that frequently require “virtual members” or “dotted-line” participants. Teams is a great way to organize a collection of people in a self-documenting way to manage permissions within CRM.
- Security Role Assignment: The security model in Dynamics CRM 2011 views users and teams almost the same, which means that you can assign a security role with, or share a record to, a team. All members of that team will have access through that security role or share as long as they remain members of that team.
- Owner Transfership: In this model, there is a commitment to share more than the cliché “need-to-know” scenario. If a team member leaves and is replaced by another person, they’ll have the same access as their predecessor when added to the team, making for a smooth transition. With a quick customization, you can even provide the team owner the power to manage membership to their team (similar to Windows security groups).
What doesn’t work in this approach:
- Permission Management: In companies where access to records is highly restrictive, team management can complicate permissions. When records are owned by users, the default is to allow access to that user, and any additional access is granted through security groups and/or sharing. Teams provides another method of managing permissions that aren’t at the forefront for those coming from CRM 4.0 or older systems. Is the record shared with a team, and should everyone on that team have access to that record?
- Team Accountability: When records are managed by users, these records are assumed by management to be managed solely by the owner. When records are owned by teams, accountability is obfuscated unless there is a well-documented role-and-responsibility for that team. If going with this model, ensure that you have these R&Rs in place.
- Customized “My Views”: Default entity views for My Items require a system customizer to modify the view to include items owned by the user’s team. It’s an easy change to make, but it needs to be modified in a number of views (including new entities) created in the future.
- No Team Hierarchy: Teams cannot be members of teams, restricting team membership to only users. This can be a limitation for those companies who have a granular team structure. Working around this would explode the number of teams required to have the same benefits.
Tony’s next post will review a Hybrid/Merged Model approach to record ownership in Dynamics CRM. To learn more about Dynamics CRM record ownership models, leave your questions and comments below, or contact us today.