Take Advantage of the New "Check Access" Command Button in Dynamics 365
Background
The other day, we had a request from one of our Dynamics 365 Customer Service clients. They asked us to remove the ‘Delete’ command button from the Case entity form. One of their users inadvertently deleted a Case record. Were they sure that happened? That user’s Security Roles did not give him delete privilege on a Case record. I spent some time researching how that could happen, then decided to put that issue on the back burner. Along with the ‘Delete’ command button, our client provided a list of additional command buttons they wanted removed from the Case form. This list included the Check Access command button. I decided to tackle that task first.
How I Stumbled across the Source of the Entity Access Security Issue
To update the Case form command ribbon, I used the XRMToolBox Ribbon Workbench tool to hide the unwanted buttons. I was able to hide all of the buttons requested by our client, except for the Check Access button. A command button with that name was not exposed in Ribbon Workbench. Honestly, I had never heard of it and didn’t know what it was. So, I published my ribbon changes in the Sandbox and opened a Case record to test it out.
The command ribbon on the Case form looked great. Of course, the Check Access button, that the client wanted removed, was still there. I was going to google it to learn more about it, but decided to just click on it instead. It ended up being the key to resolving the mystery of the deleted Case record.
How does the Check Access Command Button work?
When you click on the Check Access command button, a pop up window appears. It defaults to showing the access privileges of the currently logged in user. My user login is a System Administrator account. This explains why I have the blue checkmarks for all of the record-level privileges for the Case entity. If you click on each of the record-level privileges, the view is updated dynamically to show how that particular access is obtained, i.e. through security roles, team membership, sharing, etc.
I wanted to learn more about this new feature. I found out that Microsoft recently released this feature in Release 2021 Wave 1 across all the Dynamics 365 model-driven apps. The Check Access command can be very useful when troubleshooting entity security issues. If you have System Administrator access, you can check the access another user has to a record.
Steps to Resolving the Entity Access Security Issue
I removed my System Administrator login and used the lookup to change it to the user that inadvertently deleted the Case record. When the Check Access view for the user displayed, I saw that this user had the same record-level privileges as my System Administrator login. I certainly didn’t expect that. The Check Access view also showed that the user belongs to a Team. This Team had the System Administrator security role assigned to it and explains how that user was able to delete a Case record!
Obviously, the Team never should’ve had a System Administrator security role. After removing that security role from the Team and adding a more appropriate security role, the user can no longer delete a Case record. The Check Access view for the user displayed above indicates that the Delete record-level privilege is no longer enabled. (I must add that there were some unintended results from removing the System Administrator role from the Team. The new security role needed to be added to a few entity forms and have Run Flow enabled as well.)
We were able to kill two birds with one stone as a result of this effort. We fixed the root cause of the problem by updating the Team security role. But, we also accomplished some housekeeping and cleaned up the command ribbon on the Case form. Each task took a minimal amount of time. And, the result was a happy client!
No comment yet, add your voice below!