If you’re a Microsoft Dynamics 365 admin, you may encounter issues where users report seeing specific records they’re certain they should not have access to. In these cases, there may not be an error message to start from, so to troubleshoot you’ll have to cover your bases from top to bottom.

Scenario: User with the Sales Person role reports they can read, write, and delete opportunities for which they are not the owner. They are certain that opportunities should only allow the user level access for all three privileges.

Below are the common places to start when a user describes an issue such as the one reported above.

1. Validate the user’s role. In this case, be certain that they do in fact only have user level access for the above privileges.
   
2. Check the user’s team membership. Be certain that they are not part of special team that is giving them cumulative security access in addition to their base role.
   
3. Validate that they are not part of an access team that is allowing them special access to the records.
   
4. Check to see if the records in question have been shared with the user by another user or team in CRM.
   

Assume the above steps all check out, the user is not part of any teams with additional security permissions, the records have not been shared with them, and the role which is assigned to the user appears to be configured correctly. What next?

Sometimes cascading access from the parent record is overlooked. In our case, all users across the organization correctly have access to the CRM account entity. What we’re experiencing is the same level of access for all users to the opportunities, although looking at our access to the privileges (above) this should not be the case.

To validate, we’ll look at the relationship between account and opportunity. Out of the box we recognize that it is a one-to-many relationship (Account 1:N Opportunity). We can further validate the relationship behavior between the account and the opportunity. Here we’ll see that the behavior type is set to “Parental.” Because all our users can see all accounts, this is cascading down to the opportunity – despite our security role privileges telling us the user should see only their own opportunities.

To resolve this issue so that the security role may take full effect, we’ll update the relationship behavior between the account and the opportunity to “Configurable Cascading.” We’ll then set the assign, share, unshare, and reparent behaviors to “Cascade None.” Once these changes are published, all newly created opportunities will abide by the sales person security role which tells us a sales user can see only their own opportunities.

Note: The visibility of opportunities created prior to this update will not be adjusted retroactively and all users will still have visibility to those historic opportunities.

There you have it – don’t forget about your cascading permissions! To receive our blog posts in your inbox, subscribe here!

Happy Dynamics 365’ing!

Let’s block ads! (Why?)

PowerObjects- Bringing Focus to Dynamics CRM