GlideSystem.getUser() — ServiceNow API

gs.getUser()→ GlideUser

beginnerTested on Xanadu

What It Does

The getUser() method retrieves the GlideUser object for the current session user. ServiceNow maintains session context throughout server-side script execution, and this method taps into that context to return a wrapper object around the authenticated user's sys_user record.

Internally, ServiceNow caches the current user's information in the session and the GlideUser object provides a controlled interface to access this data. The object wraps the user's sys_user record but doesn't require database queries for basic properties — the session already has this information loaded.

The method always returns a valid GlideUser object, never null. For guest users or system operations where no specific user is authenticated, it returns a GlideUser object representing the guest user or system account. You can check user.getID() to determine if you have an actual authenticated user versus a system context.

The GlideUser object reflects the user's state at the time of the current transaction. If user properties change during a long-running script, the GlideUser object won't automatically refresh — you'd need to call getUser() again to get updated information.

This method is closely related to gs.getUserID() and gs.getUserName(), but those return individual string values while this returns the full user object with access to all properties and methods.

When to Use This

Use getUser() when you need rich information about the current user — their display name, email, department, manager, location, or roles. This is essential for business rules that make decisions based on user attributes, or for populating fields with user-related information. It's also the correct choice when building approval workflows that need to identify managers or department heads.

Don't use this method if you only need the user's sys_id or username — use gs.getUserID() or gs.getUserName() instead for better performance. Avoid the common anti-pattern of calling gs.getUser().getID() when gs.getUserID() accomplishes the same thing more efficiently.

The method only works in server-side contexts where there's a session — Business Rules, Script Includes called from the server, Scheduled Jobs running as a specific user, and similar contexts. It won't work in client-side scripts or in maintenance operations that don't have user session context.

Return Value

Returns a GlideUser object that provides methods to access user properties and check roles. The object includes methods like getName(), getDisplayName(), getEmail(), hasRole(), and getCompanyID(). The object is read-only — you can't use it to modify user properties.

The method never fails or returns null. In edge cases like system operations without a specific user context, it returns a GlideUser object representing the system user or guest user. Always check the actual user ID or username to confirm you have the user context you expect rather than assuming the returned object represents an authenticated user.

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 queries are triggered — user information is cached in the session
No Business Rules, ACLs, or other security mechanisms are bypassed — you get the user data as the session sees it
Performance is excellent since the method uses cached session data rather than database lookups
The returned GlideUser object reflects user state at transaction start, not real-time database state
Role checks through the GlideUser object respect the user's current role assignments and inherited roles
Behavior is identical across Business Rules, Script Includes, and Scheduled Jobs — the session context determines the user
No audit records are created by calling this method — it's purely a read operation

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 user information accessbasic

// Business Rule: Set incident caller information based on current user
(function executeRule(current, previous /*null when async*/) {
    var user = gs.getUser();
    
    // Populate caller fields automatically
    current.caller_id = user.getID();
    current.u_caller_email = user.getEmail();
    current.u_caller_department = user.getDepartmentID();
    
    // Set company from user's company
    if (user.getCompanyID()) {
        current.company = user.getCompanyID();
    }
    
    gs.info('Incident created by: ' + user.getDisplayName() + ' (' + user.getName() + ')');
    
})(current, previous);

Shows the most common pattern — accessing user properties to populate fields or make business decisions. Notice how we use specific methods like getID() and getEmail() rather than trying to access the underlying sys_user record directly.

Role-based workflow logicintermediate

// Business Rule: Route requests based on user's role and department
(function executeRule(current, previous /*null when async*/) {
    var user = gs.getUser();
    var assignmentGroup = '';
    
    // Managers can approve their own requests up to $5000
    if (user.hasRole('manager') && current.u_cost <= 5000) {
        current.approval = 'approved';
        current.u_approved_by = user.getID();
        return;
    }
    
    // Route based on user's department and role combination
    if (user.hasRole('itil') && user.getDepartmentID() == 'IT') {
        assignmentGroup = 'IT Operations';
    } else if (user.hasRole('facilities') || user.getLocationID() == 'headquarters') {
        assignmentGroup = 'Facilities';
    } else {
        // Default routing for regular users
        assignmentGroup = 'Service Desk';
    }
    
    current.assignment_group.setDisplayValue(assignmentGroup);
    
})(current, previous);

Demonstrates how to combine role checks with other user properties to make complex routing decisions. The hasRole() method is the proper way to check roles rather than querying the sys_user_has_role table directly.

The classic mistake — inefficient user ID lookupadvanced

// WRONG - Inefficient way to get user ID
function badGetCurrentUserId() {
    var user = gs.getUser();
    return user.getID(); // Creates unnecessary GlideUser object
}

// RIGHT - Direct and efficient
function goodGetCurrentUserId() {
    return gs.getUserID(); // Direct session lookup, no object creation
}

// WRONG - Multiple getUser() calls
function badUserCheck() {
    if (gs.getUser().hasRole('admin')) {
        return gs.getUser().getDepartmentID(); // Second getUser() call
    }
    return null;
}

// RIGHT - Cache the user object
function goodUserCheck() {
    var user = gs.getUser();
    if (user.hasRole('admin')) {
        return user.getDepartmentID(); // Reuse the same object
    }
    return null;
}

Shows the performance anti-pattern of using getUser() when you only need simple string values, and the inefficiency of making multiple getUser() calls. Cache the GlideUser object if you need multiple properties from the same user.

Gotchas

The method returns a valid GlideUser object even for guest users or system contexts — always verify you have an actual authenticated user by checking the user ID or name.

GlideUser object properties reflect the user's state when the session started, not real-time database values — if user properties change mid-transaction, call getUser() again to refresh.

Role checks through hasRole() respect inherited roles and role assignments, but don't account for elevated roles that might be temporarily assigned through role elevation.

The GlideUser object is read-only — you cannot use it to modify user properties, only to read them and make decisions based on current values.

Performance degrades if you repeatedly call getUser() in loops — cache the user object in a variable and reuse it throughout your script execution.

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