ServiceNow: How to Add Roles to Users (A Complete Guide)

By /






How to Add Roles to Users in ServiceNow: Your Comprehensive Guide to User Management



How to Add Roles to Users in ServiceNow: Your Comprehensive Guide to User Management

Welcome, fellow ServiceNow enthusiast! In the intricate world of IT Service Management (ITSM), managing who can do what is paramount. It’s not just about security; it’s about efficiency, compliance, and ensuring that your users have precisely what they need to excel without unnecessary clutter or risk. Today, we’re diving deep into a fundamental aspect of ServiceNow administration: how to add roles to users. But we won’t just scratch the surface; we’ll explore best practices, manual methods, powerful scripting techniques, and even some advanced concepts that will make you a user management maestro.

Whether you’re a seasoned ServiceNow admin, a budding developer, or someone preparing for their next big interview, understanding user roles is a cornerstone. So, grab your favorite beverage, and let’s unravel the magic of ServiceNow user management together!

Why User Roles Matter in ServiceNow: The Foundation of Access

Think of ServiceNow roles as digital keys. Each key grants access to specific doors, rooms, or even capabilities within your instance. Without the right key (role), a user might not be able to create an incident, approve a change request, or even view certain reports. It’s a robust permission system designed to:

  • Control Access: Ensure users only see and interact with what’s relevant to their job function.
  • Enhance Security: Prevent unauthorized access to sensitive data or critical system functions.
  • Streamline Workflows: Guide users through appropriate processes based on their responsibilities.
  • Maintain Compliance: Meet regulatory requirements by demonstrating strict access controls.

In essence, roles are the gatekeepers and enablers of your ServiceNow ecosystem.

The “Golden Rule”: Users, Groups, and Roles – A Best Practice

One of the first questions many new ServiceNow admins ask is: “Should I add roles directly to users or to groups?” This is a classic, and thankfully, there’s a clear answer and a widely accepted best practice.

Why Groups are Your Best Friends in ServiceNow

The unequivocal best practice in ServiceNow (and most enterprise systems, for that matter) is to add roles to groups, and then add users to those groups. Let’s break down why this isn’t just a suggestion, but a fundamental principle for scalable, secure, and maintainable user management:

  1. Scalability: Imagine you have 50 users who all need the ‘itil’ role. If you add it directly to each user, that’s 50 individual operations. If you add it to a group (e.g., ‘ITIL Users’) and then add those 50 users to the group, you’ve managed it with far fewer steps. As your organization grows, this difference becomes monumental.
  2. Efficiency: Onboarding a new employee? Simply add them to the relevant groups (e.g., ‘Help Desk Agents’, ‘HR Staff’), and they automatically inherit all the necessary roles. No need to remember every single role for every single person.
  3. Reduced Errors: Manual role assignment to individual users is prone to mistakes. Did you forget a role? Did you add an unnecessary one? Group-based management standardizes access, reducing such errors.
  4. Simplified Offboarding/Role Changes: This is a massive one! As our reference content highlights: “whenever an employee leaves an organisation and if we remove that person from the group the roles will be removed automatically.” This is a huge time-saver and a critical security measure. Similarly, if a user’s role changes within the company, you just move them to a different group (or remove them from one and add them to another).
  5. Auditing and Compliance: It’s much easier to audit “who is in the ‘Finance Approvers’ group” than to audit “who has the ‘finance_approver’ role directly assigned.” This provides a clearer, more organized trail for compliance checks.

So, while you *can* add roles directly to users, resist the urge for anything beyond highly specialized, one-off scenarios. Always lean into groups!

Manual Method: The Point-and-Click Way

Before we dive into scripting, let’s cover the foundational, manual way to manage users, groups, and roles directly within the ServiceNow user interface. This is how most day-to-day user management is performed for smaller scale operations or individual adjustments.

Adding Roles Directly to a User (Use Sparingly!)

Even though we advocate for groups, it’s essential to know how to do this. You might need to for a super-specialized user or during initial setup.

  1. Navigate to User Administration > Users.
  2. Find and click on the desired user’s record.
  3. Scroll down to the Related Lists at the bottom of the form.
  4. Locate the Roles related list.
  5. Click the Edit… button.
  6. In the slush bucket, move the desired roles from the “Available” column to the “Roles List” column.
  7. Click Save.

The user will now inherit these roles. Keep in mind: direct role assignments often lead to administrative overhead in the long run.

Adding Roles to a Group (The Recommended Path!)

This is where the magic of group-based management begins. Once roles are assigned to a group, any user added to that group instantly gains all those roles.

  1. Navigate to User Administration > Groups.
  2. Find and click on the desired group’s record (or create a new one if needed).
  3. Scroll down to the Related Lists.
  4. Locate the Roles related list.
  5. Click the Edit… button.
  6. In the slush bucket, move the desired roles from the “Available” column to the “Roles List” column.
  7. Click Save.

Now, any member of this group will automatically inherit these roles.

Adding Users to a Group

With your groups configured with roles, the final step in the manual process is adding users to those groups.

  1. Navigate to User Administration > Groups.
  2. Find and click on the desired group’s record.
  3. Scroll down to the Related Lists.
  4. Locate the Group Members related list.
  5. Click the Edit… button.
  6. In the slush bucket, move the desired users from the “Available” column to the “Group Members List” column.
  7. Click Save.

Voila! The moment a user becomes a member of a group, they gain all the roles associated with that group. This propagation is typically immediate, making group management incredibly dynamic.

Powering Up with Automation: Scripting User and Role Management

While the manual UI method is great for everyday tasks, ServiceNow truly shines with its automation capabilities. For bulk operations, integrations, or complex provisioning workflows, scripting with `GlideRecord` is your best friend. This is where you can truly accelerate your user management processes.

Understanding the Core Tables

Before we jump into code, let’s clarify the key tables involved in user and role management. Knowing these will demystify the scripting process:

  • sys_user: This is the user table. Every user account in your ServiceNow instance lives here. (Our reference confirms: “What is the user table name? Answer)sys_user”)
  • sys_user_group: This is the group table. All your user groups are defined here.
  • sys_user_grmember: This table links users to groups. It defines who is a member of which group. (Our reference confirms: “What is the group member table name? Answer)sys_user_group” – *Correction*: The reference states sys_user_group for group member, but `sys_user_grmember` is the actual group member table.)
  • sys_user_has_role: This table links users directly to roles. A record here means a specific user has a specific role.
  • sys_group_has_role: This table links groups to roles. A record here means a specific group has a specific role, which then propagates to all its members.

Creating Users with GlideRecord

Need to onboard a batch of new employees or integrate with an HR system? Scripting user creation is incredibly powerful. Here’s how you do it using `GlideRecord`:


var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record for insertion
userGr.user_name = 'jdoe_script'; // Use user_name, not username for script
userGr.first_name = 'John'; // Use first_name, not firstname
userGr.last_name = 'Doe'; // Use last_name, not lastName
userGr.email = 'jdoe_script@example.com';
userGr.active = true; // Set to active by default
var newUserId = userGr.insert(); // Inserts the record and returns its sys_id

if (newUserId) {
    gs.info('New user created successfully with sys_id: ' + newUserId);
} else {
    gs.error('Failed to create new user.');
}

Pro Tip: Always use the actual database column names (e.g., `user_name`, `first_name`, `last_name`) when scripting with `GlideRecord`, even if the UI labels are different. The `initialize()` method is crucial as it sets up a new, empty record to populate.

Creating Groups with GlideRecord

Just like users, groups can be created programmatically. This is handy when setting up new departments or project teams automatically.


var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Scripting_Team';
newGr.description = 'Team created via script for demonstration.';
// To set a manager, you'd need the sys_id of a user.
// For example, if '62826bf03710200044e0bfc8bcbe5df1' is a valid user sys_id for the manager.
// newGr.manager = '62826bf03710200044e0bfc8bcbe5df1';
newGr.email = 'scripting.team@example.com';
var newGroupId = newGr.insert();

if (newGroupId) {
    gs.info('New group created successfully with sys_id: ' + newGroupId);
} else {
    gs.error('Failed to create new group.');
}

Note: When setting reference fields like `manager`, you usually need the `sys_id` of the referenced record (in this case, a `sys_user` record).

Assigning Roles with Script (The sys_user_has_role and sys_group_has_role Tables)

This is the core of our topic. Whether you’re assigning roles directly (rarely recommended) or to groups (always recommended), you’ll be interacting with these two tables.

Scripting Roles for a User (Direct Assignment)

As mentioned, this creates a record in the `sys_user_has_role` table. The `user` and `role` fields are reference fields, so you’ll need the `sys_id` of the user and the role.


// --- IMPORTANT: Replace with actual sys_ids ---
var userId = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
var roleId = '2831a114c611228501d4ea6c309d626d'; // Sys_id of the role (e.g., 'itil')
// --- How to get a sys_id: ---
// 1. Navigate to the record (e.g., user or role).
// 2. Right-click the header, select 'Copy sys_id'.
// 3. Alternatively, open the record, and the sys_id is usually in the URL parameter 'sys_id='

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', userId); // Link to the user
userRole.setValue('role', roleId); // Link to the role
var userRoleAssignmentId = userRole.insert();

if (userRoleAssignmentId) {
    gs.info('Role assigned to user successfully: ' + userRoleAssignmentId);
} else {
    gs.error('Failed to assign role to user.');
}

Scripting Roles for a Group (Best Practice in Code!)

This is the method you’ll use most often when scripting. It creates a record in the `sys_group_has_role` table, linking a group to a role.


// --- IMPORTANT: Replace with actual sys_ids ---
var groupId = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group (e.g., 'Scripting_Team')
var roleId = '2831a114c611228501d4ea6c309d626d'; // Sys_id of the role (e.g., 'itil')

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', groupId); // Link to the group
grpRole.setValue('role', roleId); // Link to the role
var groupRoleAssignmentId = grpRole.insert();

if (groupRoleAssignmentId) {
    gs.info('Role assigned to group successfully: ' + groupRoleAssignmentId);
} else {
    gs.error('Failed to assign role to group.');
}

Managing Group Membership Programmatically

Now that you can create users and groups, and assign roles to groups, the final piece of the automation puzzle is managing group membership. This involves the `sys_user_grmember` table.

Adding a Member to a Group


// --- IMPORTANT: Replace with actual sys_ids ---
var userIdToAdd = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
var groupIdToAdd = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = userIdToAdd;
grMem.group = groupIdToAdd;
var memberId = grMem.insert();

if (memberId) {
    gs.info('User added to group successfully: ' + memberId);
} else {
    gs.error('Failed to add user to group.');
}

Removing a Member from a Group

Removing a member is a two-step process: find the existing membership record, then delete it.


// --- IMPORTANT: Replace with actual sys_ids ---
var userIdToRemove = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
var groupIdToRemove = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', userIdToRemove);
grMem.addQuery('group', groupIdToRemove);
grMem.query();

if (grMem.next()) {
    grMem.deleteRecord();
    gs.info('User removed from group successfully.');
} else {
    gs.warn('User was not found in the specified group, or record already removed.');
}

Important Note on GlideRecord: Always use `addQuery()` and `query()` before trying to delete or update an existing record. Always check `if (gr.next())` to ensure a record was found before attempting operations on it.

Beyond Basic Role Assignment: Advanced Concepts and Nifty Tricks

ServiceNow offers a rich set of features around user management that go beyond simple role assignment. Understanding these can help you tackle more complex scenarios and optimize your instance.

User Delegation: Sharing the Load

Life happens! People go on vacation, take sick leave, or just need a temporary assistant. User delegation in ServiceNow allows one user to act on behalf of another, ensuring critical workflows (like approvals) don’t grind to a halt.

“User delegation means allowing a user to work on behalf of another user within an organization. This is generally used when the original user/employee is unavailable… The delegated user gets the permissions to perform tasks and he can also get access to the resources which are normally available to the original user.”

Real-world Example: An IT Manager goes on a two-week holiday. They can delegate their approval responsibilities to a team lead. The team lead will then receive the manager’s approval requests and can act on them.

How to Set it Up (Manual):

  1. As the original user (or an admin impersonating them), navigate to the User menu (top right of the UI) and select Profile.
  2. Scroll down and click on the Delegates related list (or tab).
  3. Click New to create a new delegation record.
  4. Specify the Delegate (the user who will act on your behalf), Start date, and End date.
  5. Select the permissions you want to delegate: Approvals, Assignments, and/or Notifications.
  6. Submit.

This is a powerful feature for business continuity.

The Enigmatic Web Services User

Not all users are people! Sometimes, a third-party application needs to connect to ServiceNow to exchange data via APIs (web services). For security and clarity, we create a special kind of user for this purpose: the “Web Services User.”

“When a web services access is granted only to a 3rd party application to get connected to the ServiceNow then it is called as web services user and moreover this user can not login as a snow user into ServiceNow.”

This user typically has roles specific to the integration (e.g., `soap_admin`, `rest_service`) and is configured with appropriate authentication (like basic auth with username/password or OAuth). They are deliberately prevented from logging into the ServiceNow UI, making them a secure choice for system-to-system communication.

Knowing Your User: Client-side vs. Server-side

When you’re scripting, you often need to know who the currently logged-in user is. The method you use depends on where your script is running:

  • Client-side (Browser): Use g_user.userID;. This returns the `sys_id` of the current user. (e.g., in Client Scripts, UI Policies)
  • Server-side (ServiceNow Server): Use gs.getUserID();. This also returns the `sys_id` of the current user. (e.g., in Business Rules, Script Includes, Workflows)

Understanding this distinction is fundamental for writing robust and context-aware scripts.

Checking Group Membership: isMemberOf

A common requirement is to check if the current user belongs to a specific group. ServiceNow provides a handy server-side function for this:


// Server-side script example (e.g., in a Business Rule)
if (gs.getUser().isMemberOf('Service Desk')) {
    gs.info('Current user is a member of the Service Desk group.');
    // Perform actions specific to Service Desk members
} else {
    gs.info('Current user is NOT a member of the Service Desk group.');
}

This returns `true` or `false` and is incredibly useful for dynamic UI actions, business rules, or workflow conditions based on group affiliation.

Impersonation: Your Testing Superpower

Testing access control can be tricky. How do you know if a user with specific roles can truly see and do what they’re supposed to? Enter Impersonation!

“Impersonation: logging in as another user for testing.”

As an admin, you can temporarily become another user. This allows you to experience the instance exactly as they would, seeing their menus, data, and permissions. It’s invaluable for troubleshooting access issues, testing new configurations, and verifying role assignments. Just remember to end your impersonation when you’re done!

Access Control Lists (ACLs) and the security_admin Role

Roles dictate what capabilities a user has, but ACLs dictate what data they can access and how (read, write, create, delete). They work hand-in-hand.

To work with ACLs, you need the highly privileged security_admin role. This role is so powerful that you often have to elevate your privileges to it, even if you’re a regular `admin`.

When you create a new table in ServiceNow, it typically creates 4 default ACLs:

  • create (Allows users with required roles to create records)
  • read (Allows users with required roles to read records)
  • write (Allows users with required roles to update records)
  • delete (Allows users with required roles to delete records)

These ACLs, by default, often require the `admin` role or a role specific to the application, ensuring that your data remains protected unless explicitly granted access.

Data Lookup Roles (Brief Mention)

The reference briefly mentions “Data lookup roles.” While not directly about assigning roles to users, data lookups are a powerful feature to populate field values based on other field values. They are configured in the `sys_data_lookup` table and often involve roles in their conditions or script fields, allowing for dynamic field population based on user roles or group memberships. It’s a more advanced configuration concept but worth knowing the name.

Troubleshooting Common Role and User Issues

Even with the best intentions, things can sometimes go awry. Here are some common troubleshooting scenarios you might encounter related to roles and users:

“My user can’t see/do X!”

  • Missing Role: The most common culprit. Double-check if the user (or their group) has the necessary role for the functionality or data they’re trying to access.
  • ACL Restriction: Even with the right role, an ACL might be blocking access. Check the table and field ACLs. Remember, ACLs evaluate from most specific to most general.
  • Role Hierarchy: Does the user have a parent role that grants the necessary child role? Sometimes roles are nested.
  • Cache Issues: Occasionally, role changes don’t take effect immediately due to caching. Ask the user to log out and log back in. As an admin, you can clear the cache (`cache.do`) but use sparingly in production.
  • Personalized Forms/Lists: Is the field hidden by a user’s personalization, not an actual access restriction? Impersonate them to check.

Role Propagation Delays

While generally immediate, in very large instances or after significant system updates, you might experience a slight delay in roles propagating from groups to users. A user logging out and back in typically resolves this. If not, check system logs for errors related to group membership or role assignment.

Scripting Errors

  • Incorrect Table/Field Names: Ensure you’re using the exact database column names for `GlideRecord` operations (e.g., `user_name` instead of `username`).
  • Invalid Sys_ID: If you’re using `setValue()` with a `sys_id`, verify that the `sys_id` is correct and exists.
  • Missing `initialize()`: For new record creation, always start with `gr.initialize()`.
  • Missing `query()`/`next()`: When searching for existing records, don’t forget `gr.query()` and `if (gr.next())` before attempting operations like `deleteRecord()` or `update()`.
  • Permissions: Is the script running with sufficient permissions to create/update/delete records in the target tables? This is usually handled by the context the script runs in (e.g., an admin-level Business Rule).

Interview Insights: Acing ServiceNow User Management Questions

User and role management are evergreen topics in ServiceNow interviews. Here are some common questions and how the knowledge from this article can help you ace them:

  • “What’s the best practice for assigning roles in ServiceNow and why?”
    Answer: “Always assign roles to groups, then add users to those groups. This improves scalability, simplifies onboarding/offboarding, reduces errors, and makes auditing much easier. When an employee leaves, simply removing them from groups automatically revokes their roles.” (Refer to “The Golden Rule” section)
  • “How would you automate the creation of 100 new users and assign them to a specific group with certain roles?”
    Answer: “I would use a server-side script with `GlideRecord`. First, I’d create the users in the `sys_user` table. Then, I’d create the group in `sys_user_group` (if it doesn’t exist) and assign the necessary roles to that group using `sys_group_has_role`. Finally, I’d loop through my new users and add them to the group via the `sys_user_grmember` table.” (Refer to “Scripting” section)
  • “Explain user delegation and a scenario where you’d use it.”
    Answer: “User delegation allows one user to perform tasks on behalf of another, typically during periods of unavailability. A common scenario is when a manager goes on vacation and delegates their approval authority to a team member to ensure critical workflows continue without delay.” (Refer to “User Delegation” section)
  • “What’s the difference between `g_user.userID` and `gs.getUserID()`?”
    Answer: “`g_user.userID` is used on the client-side (browser) in scripts like Client Scripts, while `gs.getUserID()` is used on the server-side in scripts like Business Rules or Script Includes. Both return the `sys_id` of the current logged-in user.” (Refer to “Knowing Your User” section)
  • “Which role is required to work on Access Control Lists (ACLs)?”
    Answer: “The `security_admin` role is required, and often requires elevating privileges even if you’re already an `admin`.” (Refer to “ACLs” section)

Conclusion: Master Your ServiceNow User and Role Management

Congratulations! You’ve navigated the comprehensive landscape of adding roles to users in ServiceNow. From the foundational best practice of group-based management to the powerful automation capabilities of GlideRecord, and through advanced concepts like delegation and web services users, you now have a solid understanding of this critical administrative function.

Remember, effective user and role management isn’t just about technical know-how; it’s about strategic thinking. By adhering to best practices, leveraging automation where appropriate, and understanding the nuances of ServiceNow’s security model, you contribute directly to a more secure, efficient, and user-friendly instance. Keep exploring, keep learning, and keep empowering your users wisely!


Scroll to Top