.hasRole()%20in%20ServiceNow.jpg)
As a ServiceNow Developer there will be many situations where you will need to verify a user’s roles in the platform.
You may have the requirement to check user roles as a condition for a record to execute, or validate that a user has a particular role as part of a script.
Luckily, ServiceNow provides an easy way to accomplish this using gs.getUser().hasRole(). This method is a convenient tool for developers to check a user’s roles via scripting.
This article will explain what gs.getUser().hasRole() is as well as provide examples of how to use it in ServiceNow.
Let’s start by breaking down each part of gs.getUser().hasRole() in order to better understand how it works.
The first method in this line of code, gs.getUser(), will return a user object for the current logged in user.
Since “gs” is the GlideSystem API, the gs.getUser() method is available server-side and can only be used in server scripts such as Access Controls, Business Rules, UI Actions and Script Includes. To learn more about the basics of gs.getUser(), check out our complete guide to using gs.getUser().
The second method, hasRole(), takes the parameter of one or more roles, and will check if the user who is currently logged in has that role associated with their user record.
The parameter should be the name of the role from the Role table in ServiceNow.
For example, the below code will find out if the currently logged in user has the ‘business_stakeholder’ role. The code returns true or false based on if the user has that specific role.
Having the ability to check roles via scripting is useful because developers can use the result to determine what additional actions should happen in the system. In the following example, the current user has the ‘business_stakeholder’ role.
The output would be:
As mentioned previously gs.getUser().hasRole() will only work with server scripts. There is an alternative way to check user roles on the client side using g_user.hasRole().
One common place where using gs.getUser().hasRole() is useful in ServiceNow is on condition fields for server-side scripts.
Developers can take advantage of the ability to confirm user roles before allowing something to be accessible or before triggering something on the platform. One record type that has the condition field is UI Actions.
By adding gs.getUser().hasRole() as a condition for a UI Action, you can control the visibility of that action based on user roles. This can ensure that only the appropriate users have the ability to perform actions in the system.
The below screenshot shows the condition field on a UI action. This condition will return true if the logged in user has the ‘itil_admin’ role, and as a result this UI Action will be available. If the user does not have that role, the action will be hidden.
Another record that has a condition field where developers can leverage gs.getUser().hasRole() is a Business Rule. Add this code to the condition field to allow or prevent the Business Rule from firing based on roles. This works the same way as the UI Action in that if the condition returns true, the Business Rule will execute.
The following example is a Business Rule that checks the logged in user’s roles as a condition.
Additionally, you could check for more than one role in the same method as shown in the next screenshot. By passing a comma separated list of group names as the parameter, developers are able to conveniently check multiple user roles in a single statement.
The script will handle the two roles as an OR statement, meaning it will return true if the user has either of the roles specified.
In this example, the Business Rule will fire if the user has either ‘incident_manager’ or ‘change_manager’ associated with their user record.
Condition fields are not the only area where gs.getUser().hasRole() is useful. This code can also be used within any server script to check roles before performing some other action. A simple example of this is an ALC (Access Control List) script.
It may seem unnecessary to use a script to check roles for an ACL since ServiceNow provides a way to add a role using the ‘Require role’ field.
However, scripting can be useful when you need to combine role verification with another condition. Using gs.getUser().hasRole() along with other conditions in a script provides developers with the flexibility to verify other conditions along with user roles.
The following script is from an ACL script. This code will validate a user role along with the current ‘State’ of the record to evaluate if a user should be granted write access to a particular field.
There are some other ways to check for user roles that developers should have in their toolkit.
One of these methods is using gs.getUser().hasRoles() (with an “s”). This method is slightly different from the one we’ve been discussing so far. Rather than checking if the logged in user has a specific role or roles, gs.getUser().hasRoles() will verify if they have any roles at all. If the user has at least one role associated with their record, the script will return true.
Therefore, we know if the script returns false, we are dealing with a user without any roles, known as an ESS (Employee Self Service) user in ServiceNow.
Below is an example of how to use gs.getUser().hasRoles(). This script will evaluate to true if the logged in user has a role.
Up to this point we’ve been discussing how to check roles for the logged in user. But what if we need to check roles for a different user.
This can be accomplished by adding the getUserByID() method to the code we’ve been discussing thus far. Developers can use gs.getUser().getUserByID().hasRole() to verify if any user has a particular role or roles. The getUserByID() method takes a parameter of either the user ID or sys_id from the record on the User table.
The following script demonstrates how to check roles for a user who is not the logged in user.
We hope this article has helped you understand how to use gs.getUser().hasRole() in ServiceNow so that you are able to utilize it in your own scripts and take advantage of this convenient functionality. Happy coding!
Looking for something else? Check out our other posts below!
.jpg)
