CRM security is very powerful but it does have its limitations. One is that while it is possible to give someone access to a record they could not otherwise access, via Sharing, there is no clear mechanism to turn off access to a specific record. For example, let us say I work for that famous imaginary charity ‘MVPs For World Peace’ and the celebrity ambassador for the program is Ray Tomlinson, inventor of the ‘@’ symbol for emails. It is possible the events team need to capture their communications with Ray and book him as a guest speaker. However, being someone of note, it is not appropriate for everyone to have access to his details. Similarly, other notable characters may join the cause and they would also need to have their details restricted to only the events team.
Perhaps with the pending American elections, certain big name politicians may join the noble cause and different sets of users (the public relations team, for example) would need access to their information while restricting others.
So how do we set up a system in CRM such that we can create groups of Contacts (or any other entity for that matter) which only certain people can access and add records to the groups, as required?
‘Version 4’ Security Options
Back in the days of Dynamics CRM 4 we had the following tools in our security toolkit:
- Users can own records
- Visibility is at the user, business unit, business unit and child units or organization-wide
- Records can be shared with users and teams
To make records invisible on demand, we have to do something like change ownership of the record to a user in another business unit and use code to automatically share the record back to the users who are permitted access. The maintenance is messy and has the potential to clog up CRM with all the security exceptions that need to be tracked and constantly checked as records are accessed.
I have seen systems like this with literally millions of share exception records. They are unscalable and the only way to keep CRM functioning at an acceptable level is to constantly throw hardware at the problem.
2011 Security Options
The security model has changed slightly in CRM 2011 in that users AND teams can own records. Teams get a role assigned to them to determine they rights in regards to records so now all we have to do is set up the business units something like this:
In this scenario all users sit in the main business unit and have Business Unit access to all Contacts. Everyone can see all the Contacts in the system. We now create a child Business Unit and into it we add our restricted access teams (the Celebrity Team and the Political Team). These teams have a role assigned to them with user rights to Contacts. We also add the users to each team who we want to have access to the restricted records.
In the case of Ray Tomlinson, if his record is owned by a user, it ‘belongs’ to the Primary Business Unit and everyone can see it. However, if we assign it to the Celebrity Team, it now ‘belongs’ to the Restricted Access Business Unit which means no user can see it other than those who are members of the Celebrity Team and who have access to all records owned by the Celebrity Team. Problem solved, no code and no scaling issues.
There are many CRM 4 systems out there with complex code managing complicated security rules. If you are in this scenario, consider the new flexibility offered by the team ownership in CRM 2011. It is likely that by employing team ownership in creative ways, a lot of coding and maintenance time can be eliminated and CRM can be restored to a robust, scalable system.