Sharing and Cascaded Access

dsosa — Fri, 27 Feb 2009 02:18:00 GMT

A quick follow up to yesterday's post about Dynamics CRM security and cascaded access.

Jeremy Winchell, who I consider the sharpest CRM guru I've ever met and an integral member of the Inetium CRM Team, came across some issues with the cascading features of SHARING recently while working with one of his CRM 4.0 clients. Here's what he shared with our team today:

At this client we share out an Account in CRM with a CRM Team. The relationship behavior between Accounts & Contacts is as follows:

Assign -> Cascade None
Share -> Cascade All
UnShare -> Cascade All
Reparent -> Cascade None

When we share an Account the Share rules kick in and everything below it shares perfectly. However, when a new Opportunity was created for that record it was not being automatically shared. We would have to re-share the Account and let the Cascade rule take over again to reshare the record.

We finally figured out why it was not making the new Opportunity immediately shared. The issue had to do with the Reparent privilege. For some reason if this is set to Cascade None, any new records created will not automatically be shared even if the parent is shared. As soon as it was changed to All, Active or User-Owned everything started to work like a charm.

Who would’ve thought? Just thought this might be a useful piece of information.

It is! Thanks for the heads up JW!

Dynamics CRM security concepts you should know!

dsosa — Wed, 25 Feb 2009 22:29:00 GMT

The Microsoft Dynamics CRM security model is a role-based security model, where a role is conceptually some group of users (i.e. Marketing Professionals, Sales Managers...). CRM allows you to create a very granular security structure, with support for sharing and assignment of record ownership to a particular business unit. Depending on your role and sharing information, you can have access to a record even if you’re not the owner. The following concepts illustrate this:

Privileges:

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:

How privilege and access are managed

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

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.) 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 Special Sales and therefore, get brought in on certain opportunities to assist other sales reps. In order to give them access to the opportunity records they have both been added to the Special Sales Team.

Jim is working on an opportunity that involves a special sales 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 Special Sales 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, Kevin 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 and he cannot append the 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.

Sharing is also used by the CRM system 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.)

Graphically this scenario plays out like this:

The Microsoft Dynamics CRM Team Blog is a bountiful resource of information. http://blogs.msdn.com/crm/archive/2007/01/17/cascaded-security-privileges-and-sharing.aspx

Dana Sosa : Sharing, Privileges

Sharing and Cascaded Access

Dynamics CRM security concepts you should know!

Graphically this scenario plays out like this: