Sonoma Partners Microsoft CRM and Salesforce Blog

Designing Dynamics Security? Don’t Forget About Relationship Behavior

Today's blog post was written by Brian Morlock, Principal QA at Sonoma Partners.

Recently, I was testing out system access for a specific security role. This security role was setup so that a user should only have user-level permissions to the Opportunity entity, meaning that they should only be able to view and edit Opportunity records that that they own or records that have been explicitly shared with them.

Bm 1
Click the image to expand.

When I logged into CRM with a test user account who had this security role, I was surprised to find that they could see and edit some (not all) Opportunity records that were owned by other system users. 95% of the time, this would indicate that the test user is a member of a team and that team is setup with a security role that is providing the user elevated access to the Opportunity entity. When I checked the test user’s teams, I found that the test user was not a part of any teams. I also confirmed that I was looking at Opportunity records that hadn’t been explicitly shared with the test user.

At this point, it became clear that there must be some sort of data structure in place that was providing this test user access to these Opportunity records.

The commonality I discovered was that these Opportunities were associated to a Parent Account record where the test user was the owner of the Account. Aha! The test user was getting access to the Opportunity records based on their access to Account records. From a business perspective, especially for this business, this made sense, but how can this be considered when designing the security for CRM?

Answer: Cascading Parental Relationships

Bm 2
Click the image to expand.

When I viewed the relationship properties between Accounts and Opportunities in my CRM environment, I could see that the Account had a ‘Parental’ relationship to Opportunity and the Reparent setting was set to ‘Cascade All’. The key here is the Reparent setting of ‘Cascade All’. The reparent action is essentially saying, if a user is the owner of an Account, then they will automatically be granted access to any child Opportunities of that Account as if they were the actual owner of those child Opportunities.

In the example above, even though my test user was not the owner of the Opportunity, they were provided read, write, append, append to, share and assign permissions to the Opportunity simply because they were the owner of the Opportunity’s Parent Account, which is granted to them via the Reparent action of the Account to Opportunity relationship properties. Note, however, that the user will still not have permissions to delete the Opportunity, because as dictated by the security role, they do not have permission to delete Opportunity records even if they are the owner of the Opportunity record.

With the Relationship Behavior set to ‘Parental’, the Reparent action is defaulted to ‘Cascade All’ and cannot be changed. If the nature of a business dictates that the system users shouldn’t be granted permissions to an Opportunity simply because they are the owner of the Parent Account, then the Relationship Behavior can be changed to “Configurable Cascading” which allows the system administrator more flexibility in configuring the Reparent action, along with other behavior actions.

Bm 3
Click the image to expand.

Cascade All – grants ownership to all child entity records associated to the parent entity record

Cascade Active – grants ownership to only active child entity records associated to the parent entity record

Cascade User-Owner – not applicable for the Reparent action. This setting looks to apply an action to all child records that are owned by a user. The Reparent action is looking to apply ownership to child records, which the user already has. This is more applicable to the other behavior actions like Assign.

Cascade None – does not grant ownership to any of the child entity records; does nothing

Keep these Relationship Behavior options in mind if you have a complex security setup or you need to limit user access in very specific ways. They may just provide the final tweak you are looking for to create the perfect security model.

Topics: Microsoft Dynamics 365