gs.getUserID() in ServiceNow — Complete Reference with Examples

// Returns the sys_id of the current user
var currentUserID = gs.getUserID();
gs.log(currentUserID);
// Output: "6816f79cc0a8016401c5a33be04be441"

// Business Rule — check if current user is the caller
if (current.caller_id == gs.getUserID()) {
    gs.log("User is the caller on this incident");
}

var gr = new GlideRecord('incident');
gr.addQuery('assigned_to', gs.getUserID());
gr.addQuery('active', true);
gr.query();
while (gr.next()) {
    gs.log(gr.number + ' is assigned to current user');
}

var gr = new GlideRecord('task');
gr.initialize();
gr.short_description = 'New task';
gr.assigned_to = gs.getUserID();
gr.insert();

// Returns true if current user is the caller or has itil role
(function() {
    if (current.caller_id == gs.getUserID()) {
        return true;
    }
    return gs.hasRole('itil');
})()

// If you need more than just the sys_id
var user = gs.getUser();
var fullName  = user.getFullName();   // "John Smith"
var email     = user.getEmail();      // "john.smith@company.com"
var userID    = user.getID();         // Same as gs.getUserID()
var userName  = user.getName();       // "john.smith"

// Or query the sys_user table directly
var userGR = new GlideRecord('sys_user');
userGR.get(gs.getUserID());
var dept = userGR.getValue('department');

// Client Script — get current user sys_id
var currentUserID = g_user.userID;
var currentUserName = g_user.userName;
var currentUserFullName = g_user.fullName;

User properties and extended user data

Beyond the basic user identification methods, the gs.getUser() method returns a GlideUser object with additional methods for accessing extended user properties:

var user = gs.getUser();
gs.log('Company: ' + user.getCompanyID());
gs.log('Department: ' + user.getDepartmentID());
gs.log('Manager: ' + user.getManagerID());
gs.log('Roles: ' + user.getRoles().join(', '));
gs.log('Location: ' + user.getLocation());

// Check if user is in a specific group
gs.log('In Network Team: ' + gs.isUserInGroup('Network Team'));

// Check multiple roles efficiently  
var hasITIL = gs.hasRole('itil');
var hasAdmin = gs.hasRole('admin');
if (hasITIL || hasAdmin) {
    // show advanced features
}

Use getDepartmentID() and getCompanyID() (which return sys_ids) for comparisons and queries, not getDisplayValue-style methods that return names (which can change). Store and compare sys_ids; display names for human-readable output only. Related: gs object reference · ACLs · Roles vs Groups

When gs.getUserID() Returns Unexpected Values

One common source of confusion is that gs.getUserID() behaves differently depending on execution context. In a synchronous Business Rule, it returns the user who triggered the record operation. In an Scheduled Job, it returns the system user sys_id — typically the ID for the "System Administrator" account used for automated execution. In a GlideAjax server-side script, it returns the session user calling the AJAX method. Understanding these distinctions prevents a category of access control bugs where you assume a logged-in human user but actually have a service account.

Comparing User Identity Methods

ServiceNow provides several methods to identify the current user, each suited to different use cases. gs.getUserID() returns the raw sys_id string from sys_user — useful for database queries and relationship lookups. gs.getUserName() returns the user_name field (the login name, e.g. "john.doe"), which is human-readable but less reliable for queries since login names can theoretically change. gs.getUser() returns the full GlideUser object, giving you access to roles, groups, and profile fields without additional queries. For most scripting purposes, gs.getUserID() combined with a targeted GlideRecord lookup is the clearest pattern.

Practical Query Patterns with getUserID

The most common use is filtering records by the current user. To retrieve open incidents assigned to the current user:

var gr = new GlideRecord('incident');
gr.addQuery('assigned_to', gs.getUserID());
gr.addQuery('active', true);
gr.query();
while (gr.next()) {
    gs.log(gr.number + ' — ' + gr.short_description);
}

This pattern is more reliable than using gs.getUserName() in the query because assigned_to is a reference field storing sys_id values. Comparing a reference field to a username string will either fail silently or return no results. Always match the data type: reference fields take sys_id, string fields take the string value. The encoded query guide covers how to build these conditions dynamically.

Using getUserID in Client-Side Scripts

Client scripts cannot call gs.getUserID() directly — gs is a server-side object. On the client side, you access the current user via the global g_user object: g_user.userID returns the sys_id, g_user.userName returns the login name, and g_user.firstName / g_user.lastName return display name parts. If you need the user ID in a client script to make a server call, pass it as a parameter to a GlideAjax call rather than trying to retrieve it server-side from a client context.

Impersonation and getUserID

When an administrator impersonates another user, gs.getUserID() returns the impersonated user's ID, not the administrator's. This is intentional — the platform treats impersonation as a full context switch for the session. If you need to detect impersonation programmatically (for audit or bypass logic), use gs.getImpersonatingUserID(), which returns the original admin's sys_id when impersonation is active, or null when the user is running as themselves. This distinction matters in Business Rules that need to behave differently for service desk impersonation versus direct user actions.

Caching and Performance

gs.getUserID() is a fast in-memory lookup — it reads from the active session object, not the database. Calling it multiple times in a single script has no performance cost; there is no reason to cache the result in a local variable unless you need to compare it against itself later. This contrasts with gs.getUser().getMyGroups(), which can trigger a database call to load group memberships and should be called once and cached if used multiple times in a loop or complex conditional. The GlideRecord performance guide covers related patterns for minimising database calls in scripts.

Security Considerations for User ID in Scripts

Never use gs.getUserID() as the sole security gate for sensitive operations. While it reliably returns the current session user, the security model for operations should rely on ACLs and role checks as the primary control. Using gs.getUserID() to restrict access in a Business Rule script creates a server-side check that works correctly, but it is not visible in the standard ACL audit trail and is harder to maintain as your security requirements evolve. Where possible, structure your access model so that ACLs handle "who can see and modify this record" while script-based user ID checks handle application logic ("assign this record to the current user") rather than access control. This separation keeps security auditable and keeps business logic readable.

Using getUserID in Notification Scripts

Notification scripts run asynchronously and may execute in a different user context than the record change that triggered them. When a Scheduled Job updates a batch of records that each trigger notifications, the notification script's gs.getUserID() returns the job's service account, not the user originally assigned to the record. For recipient selection scripts in notifications, always derive recipient identity from the record's fields (current.assigned_to, current.caller_id) rather than from gs.getUserID(), which reflects execution context rather than the business relationship to the record. The Notification Engine guide covers recipient script patterns in detail.

Validating User Identity in Workflows

In Flow Designer flows, the current user context depends on how the flow was triggered. Flows triggered by a record change run in the context of the user who changed the record. Flows triggered by a schedule run in the system context. When a flow action calls a Script Include that uses gs.getUserID() to determine who should receive a notification or be assigned a task, testing with real user accounts (not admin impersonation) is essential to validate that the user context is what you expect. Document the expected user context in the flow's description field so future maintainers understand the assumption built into the scripted actions.

Group Membership Checks with getUserID

Combining gs.getUserID() with group membership queries enables role-like access decisions based on dynamic group assignments rather than static roles. The pattern: query sys_user_grmember where user = gs.getUserID() and group.name = 'Target Group'. This is more flexible than gs.hasRole() for situations where access should follow group membership that changes over time rather than a static role assignment. Use GlideAggregate with a COUNT for this check rather than a full GlideRecord query — you only need to know if a membership record exists, not retrieve its contents, and COUNT is faster than fetching a full record for a boolean check.