Microsoft Dynamics CRM Admins……Do you have some crm users who are willing to share some of their contacts, but other contacts (Accounts, or Leads) they would like to be “Private” or not visible to other users? If so, let’s talk about some of your options for making CRM records private.
First, a little disclaimer: generally the point of CRM systems is to share information, so any business requirement that demands individual CRM records be private ought to be questioned. Is there a broader organizational issue that is behind this need to have private records? If so, that should be address first. The solutions presented below will work for small organizations with very simple security architecture. However they will not scale to larger organizations with complex security requirements and/or larger number of records.
Now before getting into the options, let’s talk about a couple of security basics. In Microsoft Dynamics CRM 2011, the out-of-the-box security (using a combination of Business Units and Security Roles that are assigned to the user) allows you to restrict access to all records and then records that you want shared would be explicitly shared. Let’s use a common scenario as an example. Sales team members should NOT see each others Contacts or Opportunities, but others in the Organization can see them. In the illustration the sales users are in the Child Business Unit B and all others are in the Parent Business Unit A.
Another option is to hide the Sales team’s records from others in the organization. In that case, you need to sequester those who cannot see the Sales records into a separate business unit.
Now, often times the request comes up to hide only a sub-set of contacts and make them private. So the sales users want HALF of their records to be “public” or visible to others, but they want part of tem to be private.
Option 1 is to use the security show in Illustration 1 above and have the sales people explicitly share records they want others to see. To do this, you would need to create an “All Company” team and teach the users to share the records with that team. You could also code a plug-in that would share automatically based on an attribute on the record. (e.g. a bit field that says Private or Shared). This solution may not be very scalable for larger organizations since a lot of sharing may decrease performance.
Option 2 is to use Team Ownership to hide the records. So, you would create a Business Unit and a team for each Sales person where they are the only person on the team. (Note: you cannot use the default team created with the BU because members of this team must also be members of the BU). Then whenever you want to mark a record “private”, you simply assign the record to the sales person’s team (of which they are a member). Since the team is in a different BU, only the sales person will have access to records owned by that team.
In this scenario above, managers who do not have access to see all records may also be added to the individual teams of those who report them so that they may see records owned by the team. If you were creative with workflow, you could also automate this assignment (e.g. create a Private checkbox on the record, which assigns records to the team.)
There are quite a few things to consider with this architecture. Some of those include:
- Modifying Outlook sync views to ensure that items owned by the users corresponding team also sync to Outlook
- Modifying My Views to include records owned by the users corresponding team as well as the user (or creating additional views)
- Changing the ability to report on records owned by each sales person
As you can see making records “private” in Microsoft Dynamics CRM can be done. However, doing this does bring a lot of complexity to the security design.
If you found this information helpful, please ‘leave a reply’ and tell us how it worked for you.
Latest posts by JoeCRM (see all)
- How to Assign a Territory to a Lead in Dynamics CRM - May 17, 2013
- Out of the Box Report: Dynamics CRM User Summary - May 16, 2013
- Dynamics CRM / XRM Integration with GIS and PowerMap - May 15, 2013