GlideSystem.hasRole() — ServiceNow API

gs.hasRole(role)→ boolean

beginnerTested on Xanadu

What It Does

The hasRole() method performs a role membership check for the current user session. It queries the user's role assignments through the sys_user_has_role table and any roles inherited through group membership. The method handles both direct role assignments and inherited roles from groups the user belongs to.

Internally, ServiceNow maintains a role cache for each user session to avoid repeated database queries. When you call hasRole(), the platform first checks this cache. If the cache is empty or stale, ServiceNow builds the complete role list by traversing user-to-role assignments, group memberships, and inherited roles from parent groups.

The method returns true if the user has the specified role, false if they don't. It also returns false if the role name doesn't exist in the system or if you pass an empty string or null. The method never returns null or throw exceptions — it always returns a boolean.

⚠️

Users with the admin role always return true for any role check, regardless of their actual role assignments. This is ServiceNow's built-in admin bypass behavior.

The role check is case-sensitive and matches against the role's name field, not the label or sys_id. Related methods in the GlideSystem class include getRoles() which returns all roles for the current user, and getUser() which returns the current user's GlideUser object with its own role-checking methods.

When to Use This

Use hasRole() when you need to control script execution based on the current user's permissions. Common scenarios include Business Rules that should only fire for certain roles, Script Includes that need role-based logic, or Scheduled Jobs that verify the session user before performing sensitive operations. This is the standard method for role checking in server-side scripts.

Don't use hasRole() for checking roles of users other than the current session user — use GlideUser.hasRole() on a specific user object instead. Avoid using this for UI control — client-side role checks can be bypassed and should be supplemented with ACLs. Also avoid checking for the admin role specifically, since admin users return true for all role checks anyway.

Return Value

Returns a boolean value — true if the current user has the specified role or is an admin, false in all other cases. The method handles error conditions gracefully by returning false for invalid role names, empty strings, or null values. You can safely use the return value directly in conditional statements without null checking.

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.

Platform Behavior & Side Effects

No database writes occur — this is a read-only operation that only queries role assignments
Uses cached role information for performance — subsequent calls in the same session are very fast
No Business Rules, notifications, or audit records are triggered by role checking
Works identically in Business Rules (before/after), Script Includes, and Scheduled Jobs
Does not trigger ACL evaluation — this is a direct role membership check
Role cache may be rebuilt if user group memberships have changed during the session
Admin users bypass the actual role lookup entirely — admin check happens first and returns true immediately

Parameters

Name	Type	Required	Description
role	string	Yes	The name of the role to check. This is the role name, not the display name or sys_id. Case-sensitive string that must exactly match the role record's name field.

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

Code Examples

Basic role checking in a Business Rulebasic

// Before Insert Business Rule on incident table
// Only allow ITIL users to create incidents with High priority

if (current.priority == '2') { // High priority
    if (!gs.hasRole('itil')) {
        // Reset priority to Medium for non-ITIL users
        current.priority = '3';
        
        gs.addInfoMessage('Priority reset to Medium. ITIL role required for High priority incidents.');
    }
}

// Log the role check for audit purposes
gs.info('Incident ' + current.number + ' priority check: user has ITIL role = ' + gs.hasRole('itil'));

This example shows typical Business Rule usage where you check a role before allowing certain field values. The role check prevents privilege escalation while providing user feedback.

Multiple role checks with fallback logicintermediate

// Script Include method for assignment group validation
function canAssignToGroup(groupName) {
    // Admins can assign to any group
    if (gs.hasRole('admin')) {
        return true;
    }
    
    // ITIL users can assign to IT groups
    if (gs.hasRole('itil') && groupName.startsWith('IT.')) {
        return true;
    }
    
    // HR users can assign to HR groups
    if (gs.hasRole('hr_admin') && groupName.startsWith('HR.')) {
        return true;
    }
    
    // Everyone else gets default assignment group
    return false;
}

This pattern shows role-based permission cascading where you check multiple roles in priority order. Notice how admin is checked first since it would return true anyway.

The Classic Mistake — redundant admin checksadvanced

// WRONG - Redundant admin check
if (gs.hasRole('admin') || gs.hasRole('security_admin')) {
    // Execute sensitive operation
    deleteSecurityRecords();
}

// RIGHT - Admin check is automatic
if (gs.hasRole('security_admin')) {
    // Admin users will also pass this check
    deleteSecurityRecords();
}

// ALSO RIGHT - If you specifically want to exclude admin bypass
if (gs.getRoles().indexOf('security_admin') >= 0) {
    // Only users with explicit security_admin role
    deleteSecurityRecords();
}

The wrong approach explicitly checks for admin role, but admin users return true for any role check anyway. Use the explicit role list from getRoles() if you need to bypass the admin override behavior.

Gotchas

Admin users always return true for any role check, even for roles that don't exist in the system — you cannot use hasRole() to verify if an admin has specific role assignments.

The role parameter is case-sensitive and must match the role name exactly — 'ITIL' and 'itil' are different values, and only one will work depending on how the role was created.

Checking for the 'admin' role specifically is pointless since admin users return true for every role check anyway — use gs.getUser().hasRole('admin') or check gs.getRoles() if you need the actual admin role assignment.

Role inheritance through groups can cause unexpected true results — users get roles from their group memberships, and groups can have nested role assignments that aren't immediately obvious.

The method returns false for non-existent roles without any error indication — always verify your role names exist in the sys_user_role table if you're getting unexpected false results.

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