Cascaded Security Privileges and Sharing
Continuing our tradition of introducing guest speakers, here is a post by MVP and Microsoft Partner Scott Colson. Scott is the first guest speaker for 2007.
The CRM security model is a complex beast that provides a lot of granular control over who can do what with a given CRM record. I’ve recently been called on to resolve some more complex security scenarios which have really opened my eyes to two key concepts in the security model: cascading access and sharing.
Before getting into these concepts, I want to review the security basics: privilege, access, and roles.
Privilege: What a user can do with a record
In general, each user in the CRM system can be granted permission to carry out one or more of the following actions on a particular record type. This permission is referred to as a privilege:
• Create – Create a new record
• Read – View or open an existing record
• Write – Save changes to an existing record
• Delete – Delete an existing record
• Append – Append this record to another record
• Append To – Append another record to this record
• Assign – Assign this record another user
• Share – Share this record with another user
Access: Which records the user can work on
Users can have different privileges on different record types. The ability to execute a privilege (e.g. open a record for viewing) on a given record type is referred to as having access. A user is granted access based on who owns the record and how close the user is to the owner within the CRM organizational structure. There are 5 defined access levels in Microsoft CRM:
• No Access – Simply put, the user is not granted access.
• User Access – The user is granted access to only records they own
• Business Unit Access – The user is granted access to records owned by anyone in their current business unit.
• Parent Access (a.k.a. Deep Access) – The user is granted access to records owned by anyone in their business unit and to records owned by anyone in a child business unit within the organizational hierarchy
• Organization Access – The user is granted access to any records owned by any user within the organization.
Access and privilege work together to define what a user can do to a given record. For example a user may be granted User Access for the create and write privileges and Business Unit Access for the read privilege, which allows the user to view records that are owned by any user in their business unit, create their own records, and edit their own records. The user would not be able to view or edit records owned by users that were not in their business unit
Roles: Making security manageable
Microsoft CRM provides security roles as a way to manage access and privilege for each record type in CRM. Roles are analogous to Windows security groups: each CRM user is assigned one or more security roles and each security role defines the access levels and privilege for each CRM entity.
When a user is assigned more than one security role, the user is authorized the least restrictive access/privilege combination from all of the assigned roles. So if a user is assigned the Sales Person security role which allows User Access for the create, read, and write privileges on a contact record and the user is also assigned the Sales Manager security role which allows Business Unit Access for the read and write privileges, then the user would have Business Unit Access for the read and write privileges since is the least restrictive combination.
Cascaded Access – If you own the “parent” you own the child
It turns out that there is a loophole to the security model that I call Cascaded Access. Cascaded Access basically means that if a user owns the “parent” record in a relationship then that user will inherit User Access to “child” records associated with the parent. It is important to note that when you receive Cascaded Access to a record, you have no more privilege than you would if you owned the record. This is best explained by example.
Assume a CRM organization with two peer business units. Each business unit represents a sales division within the organization. Company policy is that all sales representatives are granted Organizational Access for the read, append, and append-to privileges and Business Unit Access for create and write privileges on account and contact records. Additionally, sales representatives are granted Business Unit Access on the read, append, and append-to privileges and User Access on the write and create privileges for opportunity records. All users in the organization are granted User Access for the create, read, write, and delete privilege on activities.
In this organization, Gail works in the business unit 1 and Jim works in business unit 2. Given the security setup, you would expect Jim to be able to see Gail’s account and contact records but not her opportunity records and you would expect Gail to see Jim’s account and contact records but not his opportunity records. You would also expect that they cannot see each other’s activities. You would be correct.
However, here is the loophole. If Jim is working on an opportunity associated to an account that Gail owns, then Gail will be granted User Access to the opportunity record, even though it is owned by a user from a different business unit (which appears to violate the security role setup.) My first thought when I saw this behavior was that it was a bug. But on further thought, I realized it makes a lot of sense. After all, if I were Gail, and Jim was working on an opportunity for my account, I would certainly want to know about it and track it.
Cascaded security appears to apply to all user-owned record types; however, I have only verified it on accounts, contacts, opportunities, incidents and activities. In my tests, the cascading worked down three levels (i.e., I could see activities related to opportunities related to contacts related to my account) but it may have worked even deeper in the record hierarchy. One thing to note with regard to activities is that cascading only applies to activities that are actually regarding a record. Access does not cascade based on recipients.
Sharing and Teams– Granting access across the organization
If you look at the way the access levels are setup (user, business unit, parent, organization) you see that the pattern is up and down the CRM org chart. Sharing gives you a way to grant privilege across the org chart. Teams give you a way to define groups of people from anywhere on the org chart.
Going back to my earlier example, let’s add a few more players. Kevin and Janice work with Gail in business unit 1. They both have a lot of experience with projects involving CRM integration and therefore, get brought in on certain opportunities to assist other sales reps. In order to give the access to the opportunity records they have both been added to the CRM Integration Specialist Team.
Jim is working on an opportunity that involves a significant integration and he needs some help. In order to get help, he sends an email off to Kevin and then goes into CRM and shares his opportunity record out to the CRM Integration Specialist Team.
Jim shares the record by selecting it and then going to the Actions menu and selecting Sharing. This opens a window that allows Jim to select the team and define the privileges he wants to assign to the team. (Note that he cannot share access that he doesn’t have, so in this case he could not actually share access to the delete privilege.) Jim grants the team access to the read and write privileges on his opportunity record.
Once this is done, Kevin (and Janice) can open the opportunity record and modify it. Additionally, because of Cascading Access, he can also view all of the activities related to the opportunity that he could not have viewed previously. However, Cascading Access through sharing is more restrictive than regular Cascaded Access. Since Jim only shared access to read and write privileges on the opportunity, Kevin only has Cascaded Access to the read and write privileges on the related activities.
In addition to a scenario involving teams, sharing also gives users a way to temporarily turn over a record management to another user. Rather than assigning all of my accounts to another user when I go on vacation, I can just share them out and only give the level of access needed.
BTW sharing is also used by the CRM system to during record assignment to grant previous record owners access to the record. When you assign a record that you own to another user, the record is automatically shared back to you with all 6 privileges. This gives you the opportunity to reclaim ownership of the record (at least until the new user removes your sharing rights.)
