Mastering User & Group Management in ServiceNow: From Login to Delegation

In the bustling digital corridors of any enterprise, identity is everything. Who is accessing what? What are their privileges? And how do we ensure a smooth, secure, and efficient experience for everyone? These aren’t just philosophical questions; they’re the bedrock of robust platform administration, especially within a powerhouse like ServiceNow.

ServiceNow, at its core, is designed to manage workflows, services, and IT operations. But none of that would be possible without a sophisticated, well-structured system for managing users and groups. From the moment someone logs in to the intricate delegation of tasks, understanding how ServiceNow handles identity and access is paramount.

This article isn’t just a dry technical manual; it’s your friendly guide to navigating the ins and outs of user and group management in ServiceNow. We’ll explore everything from the fundamental tables and best practices for assigning permissions, to powerful scripting techniques, understanding the current logged-in user’s context, and even advanced concepts like delegation and web services users. So, whether you’re a budding ServiceNow admin, a seasoned developer, or preparing for your next interview, let’s dive into the fascinating world of ServiceNow identities!

Understanding the Core: Users and Groups in ServiceNow

Every interaction in ServiceNow begins with a user. And more often than not, that user belongs to one or more groups. These two entities form the fundamental building blocks of access control and workflow assignment within the platform.

The Building Blocks: sys_user and sys_user_group

Think of ServiceNow as a bustling office building. Each person entering the building is a “user,” and they have their own set of credentials. These users are stored in the User table, which is officially known as sys_user. This table holds all the vital information about individuals who can access your instance: their names, email addresses, login IDs, passwords (or pointers to external authentication systems like LDAP or Okta), and much more.

Now, imagine those users don’t work in isolation; they form departments, teams, or project groups. In ServiceNow, these are represented by Groups, stored in the sys_user_group table. Groups are incredibly powerful. Instead of managing permissions for hundreds or thousands of individual users, you manage them for a handful of groups. This dramatically simplifies administration.

So, how do you link users to groups? ServiceNow uses a special table for this: sys_user_grmember. This is the glue that binds a user to a group, establishing that crucial membership relationship.

Crafting Identities: Creating Users and Groups

While you can certainly create users and groups manually through the ServiceNow user interface (go to User Administration > Users or Groups), for large-scale operations, automation is king. This is where scripting comes into play, utilizing ServiceNow’s powerful GlideRecord API.

Creating a User Account using Script

Let’s say you’re onboarding a new employee, John Doe, and you want to automate his account creation. Here’s how you can do it with a server-side script:

var userGr = new GlideRecord('sys_user'); // Instantiate GlideRecord for the User table
userGr.initialize();                      // Prepare a new record
userGr.user_name = 'jdoe';                // Set the username (login ID)
userGr.first_name = 'John';               // Set the first name
userGr.last_name = 'Doe';                 // Set the last name
userGr.email = 'jdoe@example.com';        // Set the email address
userGr.active = true;                     // Ensure the user is active
userGr.insert();                          // Save the new user record to the database

gs.info("User 'jdoe' created successfully.");
    

Practical Tip: Always set the active field to true for new users unless you specifically intend for them to be inactive initially.

Creating a Group using Script

Similarly, if you’re establishing a new team or department, you can automate group creation:

var newGr = new GlideRecord('sys_user_group'); // Instantiate GlideRecord for the Group table
newGr.initialize();                           // Prepare a new record
newGr.name = 'Development Team';              // Set the group name
newGr.description = 'Team responsible for application development.'; // Set a description
// If you have a sys_id for a manager, you can set it like this:
// newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with an actual manager's sys_id
newGr.email = 'development.team@example.com'; // Set a group email
newGr.insert();                               // Save the new group record

gs.info("Group 'Development Team' created successfully.");
    

Interview Relevance: Questions about creating users and groups via script are common, demonstrating your understanding of GlideRecord and basic system administration.

The Power of Permissions: Roles and Access Control

Creating users and groups is just the beginning. The real power comes from defining what they can *do* within the platform. This is where roles and robust access control mechanisms come into play.

Why Permissions Matter: The Role of Roles

In ServiceNow, permissions are granted through Roles. A role is essentially a collection of privileges that allows a user or group to perform specific actions, access certain modules, or view particular data. Examples include itil (for IT users), admin (for system administrators), or custom roles like hr_specialist.

Roles are assigned to users or groups, and these assignments are tracked in dedicated tables:

• sys_user_has_role: This table stores direct role assignments to individual users.
• sys_group_has_role: This table stores role assignments to groups.

Best Practice: Group-Based Permissions

While you can assign roles directly to individual users, the unequivocal best practice is to assign roles to groups, and then add users to those groups. Why? Picture this scenario:

An employee leaves your organization. If you’ve assigned 10 roles directly to that individual, you’ll need to meticulously remove each one. But if that person was a member of 3 groups, and those groups held the 10 roles, all you need to do is remove the user from those 3 groups. The roles are automatically “uninherited,” simplifying offboarding and reducing the risk of orphaned permissions. This approach scales much better and ensures consistency.

Adding a Role to a User Account using Script (for understanding, but remember the best practice!)

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // Replace with actual user sys_id
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Replace with actual role sys_id (e.g., 'itil')
userRole.insert();

gs.info("Role assigned to user directly.");
    

Adding a Role to a Group using Script (the recommended approach!)

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Replace with actual group sys_id
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Replace with actual role sys_id (e.g., 'itil')
grpRole.insert();

gs.info("Role assigned to group successfully.");
    

Troubleshooting Tip: When scripting role assignments, always ensure you’re using the correct sys_ids for both the user/group and the role. Incorrect sys_ids are a common source of error.

The Gatekeeper: security_admin Role

When it comes to the most sensitive access controls in ServiceNow – specifically, Access Control Lists (ACLs) – there’s a special role you need: security_admin. This role is highly privileged and acts as a temporary elevation of power. To perform actions like creating or modifying ACLs, a user with the security_admin role must “elevate” their privileges within the instance. This prevents accidental (or malicious) changes to fundamental security policies, adding an extra layer of protection.

Refining Data Access: Reference Qualifiers

Beyond just who can access what, you often need to control *which* specific records a user can see or select in a reference field. This is where Reference Qualifiers come in handy. They are essentially filters applied to reference and list-type fields, restricting the available options based on predefined conditions.

Simple Reference Qualifiers

This is the most straightforward type. You define a fixed query to filter records.

Example: Display only active users in a ‘Assigned To’ field.

How it works: In the dictionary entry for the field, you’d set the qualifier to active=true. Simple, right?

Dynamic Reference Qualifiers

These qualifiers adapt based on the context, often leveraging predefined “dynamic filter options.” They’re great when you need filtering logic that changes without custom scripting.

Example: Displaying only incidents assigned to the current user’s assignment group.

How it works: You’d create a dynamic filter option (e.g., via System Definition > Dynamic Filter Options) that encapsulates this logic, then select it in your reference field’s dictionary.

Advanced Reference Qualifiers (JavaScript)

When simple and dynamic aren’t enough, you turn to Advanced qualifiers, which use custom JavaScript to build complex queries.

Example: Filtering the Incident table to show only incidents assigned to the current user’s assignment group *and* with a priority less than 3.

How it works: In the dictionary entry, you select ‘Advanced’ and write JavaScript that returns a query string. For instance:

javascript: 'assignment_group=' + gs.getUser().getRecord().getValue('sys_user_group') + '^priority<3';
    

Differences at a Glance:

• Simple vs. Dynamic: Simple is static; Dynamic uses reusable, pre-configured logic that can be context-aware.
• Dynamic vs. Advanced: Dynamic is about selecting pre-built logic; Advanced is writing custom logic from scratch in JavaScript, offering ultimate flexibility.
• Simple vs. Advanced: Simple is a fixed query string; Advanced is a dynamic query string generated by JavaScript, allowing for much more complex and conditional filtering.

Interview Relevance: Expect questions on all three types of reference qualifiers, especially their differences and when to use each.

Navigating User Context: Who Am I, What Can I Do?

In many scripts, business rules, UI policies, or client scripts, you need to know who the current user is. ServiceNow provides straightforward ways to get this crucial information, depending on whether you’re on the client-side (browser) or server-side (ServiceNow instance).

The Current User: Client-Side vs. Server-Side

Getting Current Logged-in User ID (Client-Side)

When you’re writing a client script (like an ‘onChange’ or ‘onSubmit’ script) and need the user’s system ID, you’re operating within the browser context. Here, you use the global g_user object.

// In a Client Script
var currentUserID = g_user.userID;
alert("Your user ID is: " + currentUserID); // e.g., 6816f79cc0a8016401c5a33be04be441
    

The g_user object provides several useful properties beyond just the ID, like g_user.userName, g_user.getFullName(), and g_user.hasRole('rolename').

Getting Current Logged-in User ID (Server-Side)

For business rules, script includes, workflow scripts, or any other server-side processing, you’ll use the global gs object (GlideSystem).

// In a Business Rule or Script Include
var currentUserID = gs.getUserID();
gs.info("The current user's sys_id is: " + currentUserID);
    

The gs object is incredibly powerful, offering functionalities like logging (`gs.info`), checking roles (`gs.hasRole`), and much more.

Key Difference: g_user operates in the browser and is generally lighter, dealing with information already sent to the client. gs operates on the server and has full access to the database and system resources.

Are You One of Us? Checking Group Membership

Often, you need to execute logic only if the current user belongs to a specific group. ServiceNow makes this incredibly simple on the server-side.

// In a Business Rule
if (gs.getUser().isMemberOf('Service Desk')) {
    gs.addInfoMessage('Welcome, Service Desk agent!');
    // Perform Service Desk specific actions
} else {
    gs.addErrorMessage('You are not a member of the Service Desk group.');
}
    

This method returns `true` if the current user is a member of the specified group (by name), and `false` otherwise. It’s an indispensable tool for conditional logic in various server-side scripts.

Impersonation: Stepping into Another’s Shoes

Imagine you’ve built a new feature or fixed a bug, and you need to verify it works exactly as expected for a specific user type, say, a non-ITIL user. Logging out and back in as different test accounts can be cumbersome. This is where Impersonation comes in.

Impersonation allows an administrator (or anyone with the user_admin role) to “log in as” another user without knowing their password. You see the instance exactly as they would, including their roles, access, and personalized UI. It’s a lifesaver for testing user experience, troubleshooting access issues, or verifying role-based functionality. To impersonate, click on your user name in the banner frame, then ‘Impersonate User’.

Caution: While powerful, use impersonation responsibly and only for legitimate testing or troubleshooting purposes. Always remember to end impersonation when you’re done!

User Preferences: Customizing Your Experience

We all like our digital spaces to feel like our own. ServiceNow allows users to personalize certain aspects of their experience through User Preferences. These preferences are specific to an individual user and do not impact other users or the global system settings.

For instance, a user might adjust their list layout for incidents, change their homepage, or modify notification settings. These choices are stored in their user preferences, ensuring that their personalized settings persist across sessions. It’s a small but significant detail that contributes to a more human-centered platform experience.

Advanced User Management Concepts

ServiceNow goes beyond basic user and group creation, offering sophisticated features for more complex scenarios.

User Delegation: When You’re Away

Life happens. Employees go on vacation, take sick leave, or are simply unavailable. But work doesn’t stop. User Delegation in ServiceNow allows a user to empower a colleague to act on their behalf during their absence.

What it means: The delegated user temporarily gains permissions to perform tasks and access resources normally available to the original user. This is crucial for maintaining workflow continuity.

Real-world Example: An approval manager is going on a two-week holiday. Before leaving, they delegate their approval tasks to a team lead. During those two weeks, any approval requests routed to the manager will automatically go to the team lead, ensuring critical processes don’t bottleneck.

How to Configure: A user can typically set up delegation themselves. They navigate to their user account (or often through a preferences menu), scroll down to the ‘Delegates’ related list, and click ‘New’. Here, they can specify:

• Delegate: The name of the person who will cover for them.
• Start Date & End Date: The period of delegation.
• Permissions: What specifically can be delegated? Common options include:
  • Assignments: Delegate tasks assigned to the original user.
  • Notifications: Send notifications to the delegate.
  • Approvals: Allow the delegate to approve items on the original user’s behalf.

Web Services Users: The API Gateway

Not all users are human. In many enterprise environments, ServiceNow needs to integrate with third-party applications (e.g., an HR system, monitoring tool, or another ITSM platform). These integrations often require their own dedicated user accounts within ServiceNow. This is where a Web Services User comes in.

When you grant web services access to a user, it means that this “user” is primarily intended for programmatic access (APIs) by a third-party application.

Key Distinction: A web services user *cannot log in as a human user* into the ServiceNow UI. Their credentials are for machine-to-machine communication, usually via REST or SOAP APIs. This is a crucial security measure, as it separates human interaction from automated processes and helps ensure proper licensing and auditing.

Managing Group Members via Script

Just as you can create users and groups with scripts, you can also programmatically manage who belongs to which group. This is vital for automating onboarding, offboarding, and departmental changes. Remember the sys_user_grmember table? That’s what we’ll be working with.

Adding a Group Member

Let’s add John Doe (assuming his sys_id is 62826bf03710200044e0bfc8bcbe5df1) to the ‘Development Team’ group (assuming its sys_id is 477a05d153013010b846ddeeff7b1225).

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = '62826bf03710200044e0bfc8bcbe5df1';   // sys_id of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group
grMem.insert();

gs.info("User added to group successfully.");
    

Removing a Group Member

And when John Doe moves to a different team, you’ll need to remove him:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1');   // Query by user sys_id
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Query by group sys_id
grMem.query(); // Execute the query

if (grMem.next()) { // If a record is found (user is a member)
    grMem.deleteRecord(); // Delete that membership record
    gs.info("User removed from group successfully.");
} else {
    gs.info("User was not found in the specified group.");
}
    

Interview Relevance: Being able to script user and group member management demonstrates a strong grasp of ServiceNow automation capabilities.

Table Relationships: Understanding the Ecosystem

Understanding how tables relate to each other helps in grasping the full picture of data management and reporting. In the context of users and groups:

• One-to-Many Relationship: Users and Incidents

  Think of an IT department. One user (from the sys_user table) can submit or be assigned multiple incidents (from the incident table). However, each individual incident is typically assigned to only one user at a time. This is a classic one-to-many relationship: one user, many incidents.

• Many-to-Many Relationship: Incidents and Groups

  Consider a critical incident. It might involve multiple support groups (e.g., Network, Database, Application Support) to resolve. Conversely, a single support group handles many incidents. This means an incident can be associated with multiple groups, and a group can be associated with multiple incidents – a many-to-many relationship. These relationships are often managed by a “many-to-many” or “junction” table (like sys_m2m or a custom related list that creates entries linking records).

Troubleshooting Common User & Group Issues

Even with the best planning, things can go awry. Here’s a quick troubleshooting guide for common user and group-related problems:

• User Cannot Log In:
  • Check Username/Password: Simple but often overlooked.
  • Is User Active? Verify the `active` field on `sys_user` is true.
  • Login Attempts: Has the user been locked out due to too many failed attempts?
  • Authentication Source: Are they authenticating via LDAP, SSO (SAML), or local ServiceNow? Check the relevant integration logs.
  • ACLs: Rarely, but restrictive ACLs could prevent login; check system logs for denied transactions.
• User Can’t See/Access Something:
  • Missing Role: Does the user have the necessary role (or inherit it from a group) to access the module, table, or record?
  • Group Membership: Is the user a member of the correct group(s) that grant access?
  • ACLs: This is the most common culprit. Check the ACLs on the table/field in question. Use the ACL Debugger for granular insights (requires `security_admin` role).
  • Reference Qualifiers: If it’s a reference field, are reference qualifiers filtering out valid options?
  • System Properties/User Preferences: Could a system property or a user’s personal preference be hiding something?
• Script Not Working for User/Group Management:
  • Sys_IDs: Are you using the correct sys_ids for users, groups, and roles? These are often the cause of “record not found” issues.
  • Field Names: Are your `GlideRecord.setValue()` or direct assignments using the correct field names (e.g., `user_name` vs. `username`)?
  • `query()` and `next()`: For operations that retrieve existing records (like deleting a group member), ensure you call `query()` then `next()` to iterate through results.
  • Permissions: Is the user running the script (or the system user running the Business Rule) privileged enough to perform the action?
  • Logs: Check system logs (`gs.info()`, `gs.error()`) for script errors or unexpected output.
• Delegation Not Working:
  • Dates: Is the delegation period active (start/end dates correct)?
  • Permissions Checked: Were the correct permissions (e.g., ‘Approvals’) selected during delegation setup?
  • Delegated User’s Roles: Does the delegated user have a role that allows them to perform the delegated action in general?

Interview Relevance: Key Takeaways for Your Next Chat

User and group management is a foundational topic, making it a hotbed for interview questions. Be prepared to discuss:

• Best Practices: Always emphasize assigning roles to groups, not directly to users. Explain *why*.
• Core Tables: Know `sys_user`, `sys_user_group`, `sys_user_grmember`, `sys_user_has_role`, `sys_group_has_role`.
• Scripting: Demonstrate proficiency with `GlideRecord` for creating/modifying users, groups, and memberships.
• Current User Context: Differentiate `g_user.UserID` (client-side) from `gs.getUserID()` (server-side) and when to use each.
• `gs.getUser().isMemberOf()`: A common interview question – know its purpose and usage.
• Impersonation vs. Delegation: Clearly distinguish their purposes and use cases.
• `security_admin` Role: Understand its importance for ACLs and privilege elevation.
• Web Services Users: Explain their purpose and the key difference (no UI login).
• Reference Qualifiers: Be ready to explain all three types and their differences.

Conclusion: The Foundation of a Secure and Efficient ServiceNow Instance

Effective user and group management is more than just an administrative task in ServiceNow; it’s the very foundation upon which a secure, efficient, and scalable platform is built. From the granular control offered by roles and ACLs to the flexibility of delegation and the power of scripting, ServiceNow provides a comprehensive suite of tools to manage your digital workforce.

By embracing best practices like group-based role assignments, understanding the nuances of current user context, and leveraging automation through scripting, you not only enhance security but also streamline operations. This knowledge empowers you to maintain a healthy, compliant, and user-friendly ServiceNow environment, ensuring that the right people have the right access at the right time. Keep exploring, keep learning, and keep building robust solutions in ServiceNow!