As we learned in the last chapter, it's nearly always best practice to assign roles to groups, and then add users to those groups; never to add roles directly to users. This makes role management much, much easier.

Roles in ServiceNow, correspond to specific permissions. They grant access to modules within the platform, and rights to perform certain actions. Some roles, such as the admin role, grant special permissions, such as the ability to modify system records, policies, and scripts. In high security instances, there is an even higher-permissions role, called security_admin. This role grants the ability to modify security rules and run background scripts.

Roles are stored in the Roles [sys_user_role] table, and can be found in the application navigator, under User Administration | Roles. Roles are fairly simple records on their own, in that they consist primarily of a name and description. Some roles require elevation, if they have the Elevated Privilege tick-box checked. Elevation means left-clicking on your profile at the top-right of the ServiceNow interface and clicking Elevate Roles:

Roles can be created as required, and do not inherently have access to anything in ServiceNow. However, some records in ServiceNow will have the Requires role field, which allows you to select a role that's required to view or access that specific module or application. You can also use roles to control access to UI elements, such as UI Actions, or even control behavior from within scripts by using g_user.hasRole('role_name') on the client, or gs.hasRole('role_name') on the server. These methods both return a boolean true or false, allowing you to control the behavior of other scripts based on whether or not the user performing a given action, has a given role.

Here is an example of a scripted condition field using hasRole():

And here is another means of requiring a role

Note that these two conditions are evaluated separately. If a record has a Requires role field, it is not necessary to use gs.hasRole() in a separate condition field. You may however, use a different boolean expression in that field to check some other condition. You may also ignore the Requires role field, and use the condition field for everything.

Roles are linked to users via an intermediary many-to-many (M2M) table called User Roles [sys_user_has_role]. If the role is granted by the user's membership in a group (which, as a general rule, it ought to be), then the Granted by [granted_by] field is populated with a reference to the Group [sys_user_group] table. When a role is granted by a user's membership in a group, it means that a role has been assigned to the group. Much like the relationships between users and roles, the relationships between groups and roles are stored in a separate M2M table: Group Roles [sys_group_has_role].

Just like on a User record, you can grant roles to a group (and thus, to all members of that group) by modifying the Roles related list at the bottom of a Group record:

As with any related list that has the Omit Edit Button tick-box disabled under List Control, you can click Edit at the top of the list, and add roles to a group - which would then add those same roles to any user who was a member of the group!