How to Check if User Running the Plugin Has Correct Security Role in Dynamics 365

Dominic Jarvis, 30 September 2017

In certain situations, you may want to check if a user has a security role before proceeding with logic for Dynamics 365. This may be because you only want to have users with certain security roles perform these actions, or want to change the logic of the plugin slightly depending on the security roles associated with the user. In any case, the method for finding these associations is fairly simple.

Querying the Relationship

There exists an N:N relationship between Users and Security Roles in Dynamics 365. This relationship can be queried to determine if a given user is linked to a given security role.

The intersect entity is a system entity called “systemuserroles”. This intersect entity is extremely simple, and only contains three attributes: “roleid”, “systemuserid”, and “systemuserrolesid”.

These respectively are the ids for the Security Role, the User, and the Intersect entity. If you know the Guid of the role, and the Guid of the user, then you can use a simple QueryExpression to determine if there exists a relationship between the user and this role. The expression for this looks like the following:

 
However, if you don’t know the Guid of the user or the Guid of the role, this gets slightly more complex. This however, is actually a more common scenario, as Guids will change when deploying to other Dynamics 365 systems.

Obtain the Guid of the User

You can obtain the id of the user that started the plugin via the context, which has an attribute called ‘InitiatingUserId’.

If you’re simply checking the security roles of the user who executed the plugin, this will do. If not, just use a QueryExpression to obtain the Id of the user that you want.

Link the Security Role to the Intersect

If you don’t have the Guid of the Security role, it is easiest to obtain within the original QueryExpression. This is because it is possible to link the Security Role entity to the intersect, and then add a condition to the criteria for the Security Role entity. This is done through the use of LinkEntities. If you need to brush up on those, an example can be found here: https://msdn.microsoft.com/en-us/library/microsoft.xrm.sdk.query.linkentity.aspx

When linked, the code looks like the following:

This allows the user to query the system for the relevant records, given that they know the Id of the user (which can be obtained from the execution context, via a QueryExpresson, or any other viable method) and the name of the role that they want to check for. Users could even be treated like Security roles, and linked to the systemuserroles and searched for via name. This code checks to see that there is at least one Security Role with the specified name associated with this user. This is a handy check when a deployment has multiple business units, as top level security roles are duplicated in each child business unit. This means that if you check for a particular Guid, you may not get a match if you have the Guid for the right security role from the wrong business unit. In this manner, the link entity is more reliable than searching for the Guid of a Security role using a query expression, then using that Guid in the subsequent search for the relationship.