Mastering Real User Role Assignment in ServiceNow: A Deep Dive

In the dynamic world of IT service management, particularly within platforms like ServiceNow, effective user and access management is paramount. Assigning the right roles to the right users and groups is not just a technical task; it’s a strategic one that ensures security, efficiency, and compliance. As we navigate through various ServiceNow versions, from Rome all the way to the latest Washington D.C. release, the core principles of role assignment remain, but the nuances and best practices evolve. This article aims to demystify the intricacies of user role assignment in ServiceNow, drawing from real-world scenarios and practical insights.

The Foundation: Users, Groups, and Roles in ServiceNow

At its heart, ServiceNow’s security model is built around Users, Groups, and Roles. Understanding these components is the first step to mastering role assignment.

Understanding the Core Components

• Users (sys_user): These are individual accounts representing people who interact with ServiceNow. Each user has unique credentials and can be assigned roles directly or indirectly through group membership.
• Groups (sys_user_group): Groups are collections of users. Assigning roles to a group is a far more efficient and manageable approach than assigning them to individual users, especially in larger organizations.
• Roles: Roles are collections of permissions that grant users access to specific functionalities, applications, and data within ServiceNow.

Why Best Practices Matter: The Group-Centric Approach

One of the most crucial pieces of advice in ServiceNow administration is to assign roles to groups rather than directly to users. Why? It boils down to maintainability and agility. Imagine an employee leaves the organization or changes roles. If their permissions were directly assigned, you’d have to manually revoke each role. However, if their permissions were inherited through group membership, simply removing them from the relevant group automatically strips away all associated roles. This is a game-changer for efficient onboarding and offboarding processes.

As you can see from the reference (Question 3), the consensus is clear: “the best practice is to add the permissions from group…so that whenever an employee leaves an organisation and if we remove that person from the group the roles will be removed automatically.” This principle underpins much of our discussion.

Managing Users and Groups Programmatically

While the ServiceNow UI provides intuitive ways to manage users and groups, scripting offers unparalleled power and automation capabilities. This is where we can truly streamline operations.

Creating User Accounts with Scripts

When new employees join, automating the creation of their ServiceNow accounts is essential. Using the GlideRecord API is the standard method for this.

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstname = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
// You might also want to set a password, active status, etc.
// userGr.setPassword('SecurePassword123');
// userGr.active = true;
var userId = userGr.insert();
gs.info('User ' + userGr.username + ' created with sys_id: ' + userId);
        

This script directly interacts with the sys_user table to create a new user record. We initialize the record, populate the necessary fields like username, first name, last name, and email, and then use insert() to save it to the database. The returned userId is the unique system ID of the newly created user.

Creating Groups with Scripts

Similarly, when new teams or functional units are formed, you might need to create corresponding groups in ServiceNow. The process is analogous to user creation, targeting the sys_user_group table.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'IT Operations Team';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with actual Manager's sys_id
newGr.email = 'itops@example.com';
newGr.description = 'Team responsible for core IT infrastructure operations.';
var groupId = newGr.insert();
gs.info('Group ' + newGr.name + ' created with sys_id: ' + groupId);
        

Here, we’re setting the group’s name, assigning a manager (using their sys_id), providing a group email, and a descriptive text. The insert() method saves this new group.

The Mechanics of Role Assignment: Scripting It

Now, let’s dive into the core of role assignment using scripts, understanding how it translates to the underlying ServiceNow tables.

Assigning Roles to Users via Script

When you assign a role to a user through the UI, ServiceNow creates a record in the sys_user_has_role table. You can replicate this with GlideRecord.

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.user = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user
userRole.role = '2831a114c611228501d4ea6c309d626d'; // sys_id of the role
var userRoleId = userRole.insert();
gs.info('Role assigned to user. Record sys_id: ' + userRoleId);
        

This script establishes the link between a specific user (identified by their sys_id) and a specific role (also by its sys_id). This is the programmatic equivalent of navigating to a user’s form, going to the “Roles” related list, and clicking “Edit”.

Assigning Roles to Groups via Script

Similarly, assigning a role to a group creates a record in the sys_group_has_role table.

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.group = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group
grpRole.role = '2831a114c611228501d4ea6c309d626d'; // sys_id of the role
var grpRoleId = grpRole.insert();
gs.info('Role assigned to group. Record sys_id: ' + grpRoleId);
        

This is the foundational step for implementing the best practice of group-based role assignment. By assigning roles to groups, we centralize permission management.

User Delegation: Empowering Collaboration

User delegation is a powerful feature that allows one user to act on behalf of another, typically when the primary user is unavailable. This is crucial for maintaining business continuity.

What is User Delegation?

User delegation means granting another user the ability to perform tasks, access resources, and act with the permissions of the original user. This is most commonly used during vacations, leaves, or extended absences.

For instance, if an employee is on a two-week vacation, they can delegate their approval tasks to a colleague. This ensures that critical workflows, like purchase order approvals or incident resolution sign-offs, are not held up. The delegated user gains access to the original user’s context for these specific actions.

Configuring Delegation

To set this up, you navigate to the original user’s record, scroll down to the “Delegates” related list, and specify:

• Delegate: The user who will be acting on behalf of the original user.
• Start Date & End Date: The period during which the delegation is active.
• Permissions: You can selectively grant permissions for assignments, notifications, approvals, and more.

This feature is invaluable for ensuring that operations continue smoothly, even when key personnel are out of office.

Managing Group Membership Programmatically

Just as we can create groups and assign roles, managing who belongs to which group is also a common administrative task that can be automated.

Adding a Group Member

Adding a user to a group involves creating a record in the sys_user_grmember table, linking a user to a group.

var grMem = new GlideRecord('sys_user_grmember');
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group
var grMemId = grMem.insert();
gs.info('User added to group. Membership record sys_id: ' + grMemId);
        

This script establishes the membership. When a user is added to a group that has specific roles assigned, they automatically inherit those roles.

Removing a Group Member

Conversely, removing a user from a group is equally straightforward using GlideRecord to find and delete the corresponding membership record.

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // sys_id of the user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
    gs.info('User removed from group.');
} else {
    gs.info('User not found in the specified group.');
}
        

This script is vital for offboarding or when a user’s responsibilities change. By removing them from a group, they lose all the inherited roles and permissions.

Navigating ServiceNow User Interfaces

ServiceNow has evolved its user interfaces over time, offering different experiences for administrators and end-users. Understanding these helps in comprehending how features are presented and accessed.

UI Versions

As per the reference (Question 11), ServiceNow has had several user interfaces, including UI15, UI16, and the modern “Next Experience” UI. Each iteration brings design improvements, enhanced usability, and new features, but the underlying data model and core functionalities like role assignment remain consistent.

Special User Account Types

Beyond regular human users, ServiceNow supports other types of accounts for specific integration and automation purposes.

Web Services Users

A “web services user” (Question 12) is a special type of user account that is not intended for interactive login by a human. Instead, these accounts are used by external applications or scripts to authenticate and connect to ServiceNow via its APIs (e.g., REST or SOAP). They cannot log into the ServiceNow UI as a standard user would. This is critical for system-to-system integrations, ensuring secure data exchange.

Accessing Current User Information

Often, scripts need to be context-aware, utilizing information about the currently logged-in user.

Getting Current User’s System ID

ServiceNow provides simple methods to retrieve the current user’s unique identifier (sys_id).

• Client-side (Browser): Use g_user.userID. This is accessible within client scripts (like UI policies or client scripts on forms).
• Server-side (Scripts): Use gs.getUserID(). This is available in server-side scripts, such as Business Rules, Script Includes, or background scripts.

Checking Group Membership

A common requirement is to determine if the current user belongs to a specific group to control access or tailor user experience.

// Server-side check
if (gs.getUser().isMemberOf('ITIL Users')) { // Replace 'ITIL Users' with the actual group name
    gs.info('The current user is a member of the ITIL Users group.');
} else {
    gs.info('The current user is NOT a member of the ITIL Users group.');
}
        

This function, gs.getUser().isMemberOf('group name'), returns true if the current user is a member of the specified group, and false otherwise. This is incredibly useful for conditional logic in business rules or UI policies.

Troubleshooting Access Control Issues

When users can’t access what they need, or conversely, can access what they shouldn’t, troubleshooting Access Control Lists (ACLs) is key. The security_admin role is essential for this.

The Role of security_admin

The security_admin role (Question 16) is required to create, modify, or delete ACLs. This role grants broad permissions to manage security configurations across the instance, so it should be assigned judiciously.

Impersonation and User Preferences

Two features that significantly aid in testing and personalization are impersonation and user preferences.

Impersonation

Impersonation (Question 17) allows an administrator to log in and temporarily act as another user. This is invaluable for testing role assignments, validating user experience, and troubleshooting issues from a specific user’s perspective without needing their credentials.

User Preferences

User preferences (Question 18) are settings that individual users can configure to personalize their ServiceNow experience. These preferences, such as list column layouts, theme choices, or notification settings, only affect the individual user and do not have a global impact. This allows for a tailored experience for each user.

The Interplay of Incidents, Problems, and Changes

While not directly about role assignment, understanding how incidents, problems, and change requests are managed provides context for how roles are applied in practice within IT Service Management (ITSM).

Incident, Problem, and Change Definitions

• Incident (Question 19): An unplanned interruption to a service or reduction in the quality of a service. The goal is to restore normal service operation as quickly as possible.
• Problem (Question 20): The underlying cause of one or more incidents. When the same incident occurs repeatedly or affects multiple users, it indicates a problem that needs root cause analysis.
• Change Request (Question 22): A formal proposal for an alteration to some product or system. Changes are typically made to improve performance, add features, or fix underlying issues identified by problem management.

Relationship and Workflow

The relationship is cyclical: an incident is reported. If it’s a recurring issue, it can be linked to a problem record for root cause analysis. If a fix requires altering the system, a change request is created. Roles are critical here, ensuring only authorized personnel can create, assign, work on, and close these records.

Scripting Incident, Problem, and Change Records

Automating the creation of ITSM records can be a significant time-saver and ensure consistency.

Creating Incident Records

var grIncident = new GlideRecord('incident');
grIncident.initialize();
grIncident.caller_id = '86826bf03710200044e0bfc8bc5d94'; // sys_id of the caller
grIncident.category = 'inquiry';
grIncident.subcategory = 'antivirus';
grIncident.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of Configuration Item
grIncident.short_description = 'Test incident created via script';
grIncident.description = 'This incident was automatically generated to test scripting capabilities.';
grIncident.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
var incidentId = grIncident.insert();
gs.info('Incident created with sys_id: ' + incidentId);
        

Creating Problem Records

var grProblem = new GlideRecord('problem');
grProblem.initialize();
grProblem.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // sys_id of the caller
grProblem.category = 'inquiry';
grProblem.subcategory = 'antivirus';
grProblem.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of Configuration Item
grProblem.short_description = 'Test problem created via script';
grProblem.description = 'This problem record was generated to track recurring issues.';
grProblem.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
var problemId = grProblem.insert();
gs.info('Problem created with sys_id: ' + problemId);
        

Creating Change Requests

var grChange = new GlideRecord('change_request');
grChange.initialize();
grChange.category = 'inquiry';
grChange.subcategory = 'antivirus';
grChange.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of Configuration Item
grChange.short_description = 'Test change request created via script';
grChange.description = 'This change request was generated for system updates.';
grChange.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
var changeId = grChange.insert();
gs.info('Change request created with sys_id: ' + changeId);
        

Automating ITSM Workflow Logic

ServiceNow’s Business Rules are powerful for automating workflows based on record updates. Here are examples of common automation scenarios.

Auto-Closing Child Incidents When Parent is Closed

This scenario ensures that when the main incident is resolved, any related child incidents are also automatically closed.

// Business Rule: Close Child Incidents
// Table: Incident
// When: after
// Update: true
// Condition: current.state.changesTo(7) && current.parent == ''  (Assuming 7 is the 'Closed' state value)

if (current.state == 7 && current.parent == '') { // Check if state changed to Closed and it's a parent incident
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Find incidents where the 'parent' field matches the current incident's sys_id
    grChild.query();

    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed for the child incident
        grChild.update(); // Save the change
        gs.info('Closed child incident: ' + grChild.number);
    }
}
        

This Business Rule fires after an incident is updated. If the incident’s state changes to ‘Closed’ (assuming state value 7) AND it’s a parent incident (current.parent == ''), it then queries for all incidents where this current incident is listed as the parent. For each child found, it sets the state to ‘Closed’ and updates the record.

Preventing Incident Closure if Incident Tasks are Open

This ensures that an incident isn’t prematurely closed if there are still outstanding tasks associated with it. The same logic applies to problems and change requests.

// Business Rule: Prevent Incident Closure with Open Tasks
// Table: Incident
// When: before
// Update: true
// Condition: current.state.changesTo(3) // Assuming 3 is the state value for 'Closed'

var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id); // Link to the current incident
grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed' for incident tasks
grTask.query();

if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open incident tasks.');
    current.setAbortAction(true); // Prevent the update (closure)
}
        

This “before” Business Rule intercepts the update. If a user tries to change the incident’s state to ‘Closed’ (state 3), it first checks for any associated incident_task records that are not yet closed. If open tasks exist, an error message is displayed, and current.setAbortAction(true) prevents the incident from being closed.

Auto-Closing Incidents When a Problem is Closed

This scenario ensures that if the root cause (problem) is resolved, all related incidents are also closed.

// Business Rule: Close Incidents on Problem Closure
// Table: Problem
// When: after
// Update: true
// Condition: current.state.changesTo(7) // Assuming 7 is the 'Closed' state value for Problems

if (current.state == 7) { // Check if the Problem state changed to Closed
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Find incidents linked to this problem
    grIncident.addQuery('state', '!=', 7); // Ensure the incident is not already closed
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the incident state to Closed
        grIncident.update(); // Save the change
        gs.info('Closed incident associated with problem: ' + grIncident.number);
    }
}
        

Similar to the child incident logic, this “after” Business Rule on the problem table triggers when a problem is closed. It finds all incidents linked via the problem_id field that are not already closed and proceeds to close them.

Understanding ServiceNow Table Structures

ServiceNow’s platform is built on a relational database. Understanding its table structure is key to effective customization and scripting.

Out-of-the-Box vs. Custom Tables

Out-of-the-Box (OOTB) tables (Question 30) are those provided by ServiceNow and do not start with x_ (for scoped applications) or u_ (for global applications). Examples include incident, problem, change_request, sys_user, and sys_group.

Base Tables

Base tables (Question 31) are fundamental tables that many other tables extend, inheriting their fields and functionalities. The most prominent base tables are task (which all task-based records like incidents, problems, and changes extend) and cmdb_ci (for Configuration Items).

Task Table Extensions

The task table (Question 32) serves as a parent for various record types that represent work that needs to be done. Common examples that extend task include:

• incident
• problem
• change_request
• sc_req_item (Service Catalog Request Item)
• sc_task (Service Catalog Task)
• change_task

When you extend a table (Question 35), the child table inherits all fields from the parent. New fields are added to the child table, but the core structure from the parent remains. A special field called ‘class’ is added to the parent table to track which child table the record originates from.

Default Access Controls

When you create a new table, ServiceNow automatically generates four Access Control Lists (ACLs) by default if the “Create application menus and module” checkbox is selected during table creation. These ACLs typically cover:

• Read
• Write
• Create
• Delete

These provide a baseline security framework for the new table.

Number Fields and Auto-Numbering

To create unique, sequential identifiers like incident numbers, you configure “auto-number” settings (Question 34). This involves defining a prefix (e.g., ‘INC’) and the desired number of digits. ServiceNow then automatically assigns incremental numbers with the specified format to new records.

Field Types and Configuration

ServiceNow offers a rich variety of field types to capture diverse data.

Common Field Types

Here are some frequently used field types (Question 36):

• Reference
• String
• List
• Choice
• Email
• Date/Time
• Date
• Boolean
• Integer
• Journal
• Attachment

Temporary vs. Normal Tables

ServiceNow distinguishes between table types (Question 37):

• Normal Tables: Store data permanently.
• Temporary Tables: Store data for a limited duration (typically 7 days) and extend the import_set_row table. They are often used for staging data during import processes.

The retention period for temporary tables can be extended using archive rules (Question 38).

Remote Tables

Remote tables allow you to access live data from external systems directly within ServiceNow. Unlike normal tables that store data locally, remote tables display real-time information from the source, enabling integrations without data duplication.

Table Relationships

Understanding how tables relate to each other is crucial for building efficient and well-structured applications.

One-to-One, One-to-Many, and Many-to-Many

• One-to-Many: A single record in Table A can relate to multiple records in Table B, but each record in Table B relates to only one record in Table A. Example: A user (Table A) can have many incidents (Table B). (Question 40)
• Many-to-Many: A record in Table A can relate to multiple records in Table B, and vice-versa. This is typically implemented using a “join table.” Example: Incidents (Table A) and Groups (Table B) – an incident can be assigned to multiple groups, and a group can work on multiple incidents. This often involves a table like sys_user_group.incident. (Question 40)

Creating and Modifying Records

ServiceNow provides multiple avenues for data entry and manipulation.

Ways to Create Records

Records can be created through various methods (Question 41):

• UI Forms
• Record Producers
• Email Inbound Actions
• Scripts (using GlideRecord)
• Import Sets (via Excel or other file formats)
• External systems via web services

Making Fields Mandatory or Read-Only

Several mechanisms exist to control field behavior (Question 42):

• Dictionary Properties: Directly on the field’s dictionary entry.
• Dictionary Overrides: To modify parent table field behavior in child tables.
• UI Policies: Client-side logic to change field visibility, mandatory, read-only, or default values based on conditions.
• Data Policies: Similar to UI Policies but operate on both client and server sides, ensuring data integrity regardless of the access method.
• Client-side Scripts: Using g_form.setMandatory() or g_form.setReadOnly() for dynamic control.
• Server-side Scripts: Using current.setMandatory() or current.setReadOnly() in Business Rules or other server scripts.

Display Fields

A table can have only one field designated as a “display” field. This field is used in related lists and other contexts to represent the record. Having multiple display fields would lead to ambiguity and confusion (Question 43).

Default Values

You can set default values for fields (Question 45). This populates the field with a predefined value when a new record is created, reducing manual entry and ensuring consistency. This can be done via dictionary entries, UI Policies, or Data Policies.

Advanced Field Configuration

ServiceNow offers sophisticated ways to refine field behavior and data presentation.

Reference Qualifiers

Reference qualifiers are essential for filtering the records that appear in reference and list fields. They act like dynamic `WHERE` clauses for your reference lookups.

• Simple Reference Qualifier: Uses fixed conditions. Example: active=true to show only active users.
• Dynamic Reference Qualifier: Uses dynamically generated queries based on context. This is configured via “Dynamic Filter Options.”
• Advanced Reference Qualifier (JavaScript): Allows complex JavaScript logic to dynamically filter records. This provides the most flexibility.

For example, an advanced qualifier could filter a list of incidents to show only those assigned to the current user’s group AND with a priority less than 3 (Question 48).

Dependent Values

Dependent values create cascaded dropdowns. When a user selects a value in a “parent” field (e.g., Category), the choices available in a “dependent” field (e.g., Subcategory) are filtered to show only relevant options. This improves data accuracy and user experience (Question 49).

Calculated Values

Calculated fields derive their value from an expression or script. You define a formula or script in the dictionary entry, and ServiceNow automatically computes the field’s value based on other fields (Question 50). For instance, a “Total Cost” field might be calculated by multiplying “Quantity” and “Unit Price”.

Attributes

Attributes are special keywords applied to fields or tables to modify their behavior. Examples include no_email (to prevent email notifications for changes to this field), no_attachment (to disable attachments for a specific field or table), or tree_picker (for hierarchical selection). You can control attachment behavior by using the no_attachment attribute in the collection field’s attributes (Question 53).

Dictionary Overrides

When you need to modify a field’s behavior in a child table differently from its parent, you use Dictionary Overrides (Question 54). For example, you might change the default value of a “Priority” field from 4 (in the parent `task` table) to 5 specifically for the `incident` table.

UI Policies and Data Policies

These features are critical for creating dynamic and user-friendly forms.

UI Policies

UI Policies execute client-side to control field visibility, mandatory status, read-only status, and default values based on specific conditions. The global checkbox makes the UI policy apply across all views; otherwise, you specify views. The Reverse if false option means the policy’s actions are undone when the condition is no longer met. The On Load checkbox ensures the policy is evaluated when the form initially loads (Question 61).

Data Policies

Data policies, like UI policies, enforce mandatory, read-only, or display settings for fields based on conditions. However, they operate on both the client and server, ensuring data integrity regardless of how the record is accessed (UI form, API, import). While UI policies are primarily for user interface manipulation, data policies are focused on data governance.

Converting UI Policies to Data Policies

ServiceNow allows conversion of UI policies to data policies (Question 64). However, this is not possible in all scenarios. You cannot convert UI policies that control data visibility, views, related lists, or complex scripting directly into data policies (Question 65).

Application Menus and Process Flows

These elements enhance user navigation and workflow visualization.

Application Menus (Modules)

Application Menus, often referred to as modules, are used to make forms and lists accessible to end-users. They appear in the left-hand navigation menu, organizing access to different applications and modules within ServiceNow (Question 55).

Process Flows

Process flows provide a visual representation of the current stage of a record within its lifecycle. They indicate the state of a form and guide users through a defined workflow, improving process adherence and clarity (Question 56).

Interview Relevance

Conclusion

Mastering user role assignment in ServiceNow is fundamental to building a secure, efficient, and well-managed platform. From understanding the core components of users, groups, and roles to leveraging scripting for automation and adhering to best practices like group-based role assignment, every aspect contributes to a robust ITSM environment. As ServiceNow continues to evolve with new versions and UI enhancements, the foundational principles of access control remain critical. By drawing on practical insights, understanding the underlying database structure, and applying the right automation techniques, administrators can effectively manage user access and empower their organizations.

This comprehensive overview, grounded in practical examples and best practices, aims to equip you with the knowledge to confidently handle real user role assignment scenarios in ServiceNow, whether you’re performing daily administration or preparing for a technical interview.