sys_user_has_role Table

Table Reference/sys_user_has_role

The `sys_user_has_role` table stores direct role assignments to individual users, separate from group-inherited roles. Owned by the Platform module, the critical thing to know is that this only shows explicit assignments — not inherited roles from groups.

What This Table Is

The sys_user_has_role table stores direct role assignments to individual users. This is the junction table that creates many-to-many relationships between sys_user and sys_user_role records. When you explicitly assign a role to a user through the platform UI or via script, a record gets created here.

This table is owned by the Platform module and supports the core identity and access management process. It's part of the broader role-based access control (RBAC) system that determines what users can see and do in the platform. Every record represents one user having one role through direct assignment, not inheritance.

This is a standalone table that doesn't extend any parent table. No other tables extend from it. The relationship structure is simple: it references sys_user for the user and sys_user_role for the role, with additional metadata about the assignment itself.

In large enterprises, this table typically contains 50,000-500,000 records depending on how heavily they rely on direct role assignments versus group memberships. Performance is generally good since it's a simple junction table with indexed reference fields. The biggest volume comes from organizations that assign incident-specific or project-specific roles directly rather than managing them through groups.

When You'll Script Against This Table

You'll most commonly script against this table in Business Rules that need to verify user permissions, Script Includes that handle role management, and Scheduled Jobs that audit role assignments. It's also frequently queried in ACL scripts, Transform Maps during user imports, and custom applications that need to understand user capabilities. Background scripts often hit this table when cleaning up role assignments or performing bulk role management.

Access to this table requires the user_admin role for write operations, though read access is available to users who can view user records. Global scope applications can freely query this table, but scoped applications have limited access and typically need to use platform APIs rather than direct GlideRecord queries.

Role verification — checking if a specific user has a specific role directly assigned
Bulk role assignment — programmatically adding roles to users based on business logic
Role cleanup — removing expired or inappropriate direct role assignments
Audit reporting — identifying who has what roles through direct assignment vs groups
User onboarding — automatically assigning standard roles based on department or job function
Role inheritance analysis — comparing direct assignments to group-inherited roles
Temporary role grants — implementing time-bound role assignments with custom logic

Table Gotchas

⚠️

This table only shows direct role assignments, not inherited roles from groups. Use gs.hasRole() or the User object's hasRole() method to check effective permissions including group inheritance.

⚠️

The state field defaults to 'active' but can be set to 'inactive' to temporarily disable a role assignment without deleting the record. Many developers miss inactive assignments in their queries.

Duplicate prevention isn't enforced at the database level — you can create multiple active records for the same user-role combination, which can cause confusion in role management
The granted_by field is often empty for system-created assignments, making it hard to track assignment origins

⚠️

Deleting records from this table immediately affects user permissions. There's no soft delete or approval process — the role is instantly removed from the user.

Performance can degrade when joining this table with large user queries — the user and role reference fields are indexed, but compound queries across all three tables can be slow
The inh_count field is a computed counter that can become stale and doesn't accurately reflect current inheritance in all cases

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The two primary related tables are sys_user and sys_user_role, which this table connects through foreign key relationships. You'll frequently join all three when building user management interfaces or generating role assignment reports. The sys_user_grmember table is equally important because it shows role inheritance through group membership, which is often more significant than direct assignments.

The sys_user_role_contains table defines role hierarchy and inheritance, so you'll query it alongside this table when you need to understand the full scope of permissions a user receives from a direct role assignment. For audit trails, the sys_audit table tracks changes to role assignments when auditing is enabled.

For complete access control analysis, developers typically query this table alongside sys_group_has_role and sys_user_group to get the complete picture of how users acquire their effective roles. This is particularly important for compliance reporting where you need to document all paths by which a user gains specific permissions.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
user	reference	User	References sys_user. The user receiving the direct role assignment. Cannot be empty and must reference an active user record.
role	reference	Role	References sys_user_role. The role being directly assigned to the user. System roles like 'admin' appear here alongside custom roles.
state	choice	State	Active or inactive status of the role assignment. Defaults to 'active' but can be set to 'inactive' to temporarily disable without deletion.
granted_by	reference	Granted by	References sys_user for who created this assignment. Often empty for system-generated assignments, making audit trails incomplete.
inh_count	integer	Inheritance count	Computed field showing inheritance depth. Can become stale and shouldn't be relied upon for real-time permission calculations.
included_in_role	reference	Included in role	References sys_user_role when this assignment exists due to role inheritance. Empty for true direct assignments.
included_in_role_instance	reference	Included in role instance	References the specific sys_user_has_role record that caused this inheritance. Used internally by the role inheritance engine.

Common Queries

Get all active role assignments for a specific user

// Most common query - check what roles a user has directly assigned
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('user', user_sys_id);
gr.addQuery('state', 'active');
gr.query();

while (gr.next()) {
    var roleName = gr.role.name.toString();
    gs.info('User has role: ' + roleName);
}

// Remember: this only shows direct assignments, not group inheritance

Find all users with a specific role directly assigned

// Business scenario: find all users with 'incident_manager' role
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('role.name', 'incident_manager');
gr.addQuery('state', 'active');
gr.addQuery('user.active', 'true'); // Only active users
gr.query();

var userList = [];
while (gr.next()) {
    userList.push({
        name: gr.user.name.toString(),
        email: gr.user.email.toString()
    });
}

gs.info('Found ' + userList.length + ' active incident managers');

Check if a user has a specific role through direct assignment

// Real-world: verify user has admin role before allowing operation
var hasDirectAdminRole = false;
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('user', gs.getUserID());
gr.addQuery('role.name', 'admin');
gr.addQuery('state', 'active');
gr.setLimit(1);
gr.query();

if (gr.hasNext()) {
    hasDirectAdminRole = true;
    gs.info('User has admin through direct assignment');
} else {
    gs.info('User might have admin through groups - check gs.hasRole()');
}

Count role assignments by role using GlideAggregate

// Audit report: how many direct assignments per role
var ga = new GlideAggregate('sys_user_has_role');
ga.addQuery('state', 'active');
ga.addAggregate('COUNT');
ga.groupBy('role');
ga.query();

while (ga.next()) {
    var roleName = ga.role.name.toString();
    var assignmentCount = ga.getAggregate('COUNT');
    gs.info(roleName + ': ' + assignmentCount + ' direct assignments');
}

// Useful for identifying over-used roles that should be managed via groups

Wrong way vs right way to check user permissions

// WRONG: Only checking direct assignments misses group inheritance
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('user', user_id);
gr.addQuery('role.name', 'itil');
var hasRole = gr.hasNext(); // Incomplete check!

// RIGHT: Use platform API that includes all inheritance
var hasRole = gs.hasRole('itil'); // In server script
// or: new GlideUser(user_id).hasRole('itil'); // For other users

// Only query sys_user_has_role when you specifically need direct assignments

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

sys_user_has_role