There are many instances where businesses want multiple “owners” of something within CRM.  Having multiple users own something comes in many different forms when related to CRM. Examples include team selling using CRM Opportunity records, team support using Cases, and Tasks assigned to a group. Microsoft CRM is constructed such that one user is the “owner” of each record within CRM.  Can we alter the system to modify this ownership?

Depending on the functionality you are looking to support, assigning multiple owners to a record can be accomplished many different ways in CRM.  The question to start with is what functionality your business needs to support with multiple “owners” of something within in CRM.  Are you trying to designate multiple individuals who are responsible for a record or task for reporting purposes?  Are you trying to allow users to sync sets of data offline or contacts to Outlook without creating a separate local data filter for each account, opportunity or contact they want offline?  Are you trying to restrict and grant access for people to be able to see and update records?  Are you trying to provide users with an easy way to view the records for which they are a partial “owner”?

Today we will be looking into one of these scenarios: the need to restrict access to records based on the multiple owners of the record.

For this example, let’s assume we have a very restrictive access within our CRM system which requires only the owners of an Opportunity the ability to edit it.  This would work easily if the opportunity only had one owner but in this case each opportunity is handled by three people.  These three people are the field salesperson, the field salesperson inside sales counterpart and an assigned technical support staff who is assigned per opportunity.

Now that we have defined what functionality we want we can begin designing how to accomplish it within CRM.  To do this we first need to understand how a few things work in CRM by default and then begin to build on top of that based on the functionality we are looking for.

Microsoft CRM Security Structure

How does Security work within Microsoft CRM? How does owning a record in CRM relate to security?

Microsoft CRM by default has records in CRM that are either owned at the Organization, Business Unit or the User level.  You can only create new entities that are either Organization or User owned.  The ownership of records within Microsoft CRM is directly linked to security and granting or denying access to records. 

We cannot change the default ownership structure within Microsoft CRM.  All records in Microsoft CRM will either be owned by the Organization or a Business Unit or a single User.  That is not a customizable option for entities in the system or new entities we create.  This means that we will have to build a new “ownership” structure that will facilitate our requested functionality.  

Basically, record access can be granted at 4 levels:

• Organization (You can perform the action no matter where you or the record exists)
• Deep or Parent/Child Business Unit (You can Perform the action as long as the record is in your business unit or a business unit underneath your business unit in the hierarchy)
• Business Unit (You can perform the action as long as the record is in your business unit)
• User Owned (You can only perform the action as long as you are the owner of the record)

Microsoft CRM also provides the ability for users to grant access to a record they own to other users. This is called sharing.  Users can either share records to specific users or create a team within CRM that contains multiple users and share to the team thereby giving everyone in the team the access that they just granted to the team.

Design Options

Now that we have an understanding of how Microsoft CRM uses record ownership and we have our functionality requirements we can begin to design a system that could accomplish the functionality we are looking for. 

Manual Process using Sharing

The first option is to use the built-in security capability, along with a manual process, to provide this functionality to users. 

To do this, you would simply create a security role that only allows users to see and edit opportunities for which they are the owner.

Then, after a user creates an opportunity where they need help from someone else on they can share that opportunity to the other user and grant them access to see and update the opportunity.

PROS

No custom coding
Uses the standard built-in functionality

CONS

Requires users to manually add each person to each opportunity they create or need access to. 
Not a simple way to see those who have access to the record.
If a user forgets others who should be able to see it cannot see the opportunity.

Auto Sharing

The second option is to use the built-in security options along with an automatic process to automatically share the opportunity to their counterpart. 

The solution is to create a security role that only allows users to see and edit opportunities for which they are the owner.  Then, when a user creates an opportunity a custom Plug-in would automatically share out the record to their counterpart based on the owner of the opportunity.  The user would still have to manually share out for the Technical Support because they are assigned on an opportunity by opportunity basis.

PROS

Reduces the user’s manual work to share out records in the system.
Uses the standard built-in functionality with minimal coding.

CONS

Requires users to manually add each technical support person to each opportunity.
Not a simple way to see those who have access to the record.
If a user forgets others who should be able to see it cannot see the opportunity.
If a field reps counterpart changes could require a code change for the sharing or at least a configuration change.

Auto Sharing using Custom Relationships

In this option, we accommodate up to three people who will have access to the opportunity, as stated in our functionality requirements.  We use the built-in security options to lock down the data within CRM.  We then change the label on the Opportunity Form for the standard owner to now say “Field Rep”. We then create two new N:1 relationships from Opportunities to Users.  The first one is called “Inside Rep” and the second one called “Technical Rep”.  We then put the two new fields on the Opportunity Form. We then create a Plug-in on the opportunity that automatically shares the Opportunity to the user that is selected in the Inside Sales or Field Rep relationship.

PROS

Shows on the Opportunity form who is working on the opportunity.
Uses the standard built-in functionality with minimal custom code.

CONS

Limits the solution to only three “owners” for each opportunity.

Conclusion

There are many different ways this version of “multiple owners” can be accomplished within Microsoft CRM.  We covered three simple routes but there are many other ways to accomplish similar functionality.  Your businesses specific requirements along with user training/abilities and volume of data can determine which approach will work best for your business.

- Hoss Hostetler