Dynamics CRM 2011 provided a number of evolutions across the board, but none more impactful than the introduction of team ownership. Prior to Dynamics CRM 2011, the method for assigning record ownership was relatively straight forward. You would assign the records to a user and manage access via assignments, sharing, or through expanded security roles. Team ownership provides a parallel akin to its big brother; security groups used in the Windows platform. However, team ownership has also generated a decision point for system administrators and customizers. In this series of posts, I’ll demonstrate the strengths and weaknesses of each approach, giving you the perspective you need to decide the right approach for your solution.
Getting To Know the Options
This series of posts will focus on the two main ownership approaches in Dynamics CRM 2011: System User Ownership and Team Ownership. (Note: it is possible for items to be owned by organizations or routed to queues, but these scenarios are not relevant for business unit or team ownership.)
For those new to customizing Dynamics CRM, System User Ownership is where you organize your system users in a hierarchy of business units and then expand their permissions to records via security roles. This model leverages a company’s natural management structure to guide permissions to records, commonly referred as a top-down permission model. In this model, the parent business units typically have access to its child business unit records. For example, if my company used this model, my manager would have access to my account or contact records, but I would probably not have to access his/hers.
The second type of ownership in this discussion is Team Ownership. Teams have been available in the Dynamics CRM platform since version 1.0, but in Dynamics CRM 2011 they have been endowed with the ability to own records. Teams are a collection of system users spanning multiple business units who share a logical association. In a large company of 1,000+ users, you will find multiple employees performing the same job, but operating in different divisions. An example of this is a company that uses a federated management structure of many divisions (corporate sales, vendor sales, customer support, engineering, etc.) where each division has their own financial controller. With team ownership, you could add all financial controllers across the company to a Dynamics CRM team named “Financial Controller Team”, and grant all members of that team access to specific records or entities. All members of this team could be granted read/write access to contracts and invoices across all divisions in the company.
Approach 1: Business Units
Although it’s not uncommon for businesses to have child businesses, my experience has shown me that the common use of Dynamics CRM business units is related to a company’s internal divisional structure. This is a great approach for companies whose management teams have organized the company to work in a silo structure. The ownership of records is clean (for example, finance records are owned by individual users within the finance team). Access to those records can be granted via the sharing feature in Dynamics CRM, or by modifying the security roles to grant those users business unit visibility.
What works in this approach:
- BOL (Behind On the Line): Record accountability is always tied to a specific person, and that person is accountable for any updates or follow-up with the owned record.
- Clean Escalation Paths: For Dynamics CRM deployments where the system administrator is diligent about tracking management chains, it is easy to navigate a chain of command within CRM by quickly identifying an owner’s manager. This model provides an excellent starting point for that navigation.
- Restrictive Security Model: Ownership of a record is quickly identified. Finding out who else has access to that record requires only the owner’s business unit roles and the list of people who have been shared access to the record.
- Out-of-box “My [entity]” Views: Default views are usable without any modification.
What doesn’t work in this approach:
- Ownership Transfer: In the event that an employee leaves the company, the responsibility of transferring ownership from one user to another falls on the owner’s manager or data administrator (security role permitting). The pain factor involved with this activity is directly related to the attrition rate at your company!
In upcoming posts, we will review the Team Ownership approach, and take a look at a Hybrid/Merged Model approach. To learn more about Dynamics CRM record ownership models, leave your questions and comments below, or contact us today. You can also sign up for our newsletter, which provides insights into Dynamics CRM and Business Intelligence, free software downloads, promos, and more.