GlideSystem.getSession() — ServiceNow API

gs.getSession()→ GlideSession

intermediateTested on Xanadu

What It Does

The getSession() method retrieves the current user's session object, which contains contextual information about their active ServiceNow session. The session object persists throughout the user's interaction with the platform and provides access to timezone settings, language preferences, client IP address, and other session-specific data that may not be directly available through other APIs.

Internally, ServiceNow maintains session state in memory and ties it to the user's authentication token or session cookie. When you call gs.getSession(), the platform looks up the current execution context and returns the associated GlideSession object. This works reliably in user-initiated contexts like Business Rules triggered by form submissions, but behaves differently in system-initiated contexts like scheduled jobs.

The method always returns a GlideSession object, never null. However, the session object's properties may contain different values depending on the execution context. In scheduled jobs or system processes, the session represents the system context rather than a specific user's session, which means timezone and language settings default to system values rather than user preferences.

Edge cases occur when the execution context changes mid-process. For example, if a Business Rule calls a Script Include that performs an impersonation using gs.getUser().impersonate(), the session object continues to reflect the original user's session data, not the impersonated user's preferences. The session is bound to the HTTP request context, not the current user context.

This method differs from gs.getUser() in that it focuses on session-level data rather than user profile data. While getUser() returns user record information and roles, getSession() returns contextual information about how the user is currently interacting with the platform.

When to Use This

Use getSession() when you need to access timezone information for date formatting, determine the user's language for internationalization, or retrieve client-specific data like IP address for logging or security purposes. This method is particularly valuable in Business Rules that need to format dates or times according to the user's timezone preferences, or in Script Includes that generate localized content.

Avoid using this method when you need user profile information like roles, departments, or contact details—use gs.getUser() instead. Don't use session data for security decisions since session properties can be manipulated on the client side. Session data should inform presentation and formatting decisions, not access control or business logic validation.

Common misuse includes storing sensitive data in session variables or assuming session data persists across different types of script execution. Session variables set in one Business Rule may not be available in asynchronous processes or scheduled jobs that run later.

Return Value

The method returns a GlideSession object that provides methods like getTimeZoneName(), getLanguage(), getClientIP(), and property access methods. The object is always instantiated, so you don't need null checks on the session object itself, but individual property values may be empty strings or default values depending on the context.

The returned object is live and connected to the current session state. Changes made to session properties through the GlideSession object's methods will persist for the duration of that user's session, making it useful for maintaining state across multiple requests within the same session.

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 Business Rules, notifications, or audit records are generated by simply calling this method—it's a read-only operation
No database writes occur unless you modify session properties through the returned GlideSession object's setter methods
Performance is fast—session objects are cached in memory and retrieved without database queries
Behavior is consistent across before/after Business Rules and Script Includes when called within the same HTTP request
In scheduled jobs and system processes, returns a system session object with default timezone and language settings rather than user-specific values
Session modifications may not be immediately visible in client-side scripts since they operate in a different execution context

⚠️

Session data persists only for the duration of the user's active session and should never be relied upon for permanent data storage or cross-session state management.

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 session information retrievalbasic

// Business Rule to log session context for incident creation
(function executeRule(current, previous) {
    var session = gs.getSession();
    var timeZone = session.getTimeZoneName();
    var language = session.getLanguage();
    var clientIP = session.getClientIP();
    
    // Format the opened_at field using user's timezone
    var gdt = new GlideDateTime();
    gdt.setDisplayValue(current.opened_at.getDisplayValue(), timeZone);
    
    gs.info('Incident {0} created by user in timezone {1}, language {2}, from IP {3}',
           [current.number, timeZone, language, clientIP]);
    
    // Set a work note with timezone-aware formatting
    current.work_notes = 'Incident logged at ' + gdt.getDisplayValue() + 
                        ' (' + timeZone + ')';
})(current, previous);

This example shows how to retrieve basic session information and use timezone data for proper date formatting, which is essential for global ServiceNow implementations.

Session-based conditional logic in Script Includeintermediate

var SessionUtils = Class.create();
SessionUtils.prototype = {
    initialize: function() {
        this.session = gs.getSession();
    },
    
    getLocalizedMessage: function(messageKey, params) {
        var lang = this.session.getLanguage();
        
        // Route to appropriate message based on session language
        if (lang === 'es') {
            return this._getSpanishMessage(messageKey, params);
        } else if (lang === 'fr') {
            return this._getFrenchMessage(messageKey, params);
        }
        return this._getEnglishMessage(messageKey, params);
    },
    
    isInternalUser: function() {
        var clientIP = this.session.getClientIP();
        // Check if user is accessing from internal network
        return clientIP.startsWith('10.') || clientIP.startsWith('192.168.');
    },
    
    type: 'SessionUtils'
};

This pattern demonstrates using session data for internationalization and client context awareness in reusable Script Includes.

The classic mistake - assuming session availabilityadvanced

// WRONG: This fails in scheduled jobs
var ScheduledScript = Class.create();
ScheduledScript.prototype = {
    execute: function() {
        var session = gs.getSession();
        var userTimezone = session.getTimeZoneName(); // Returns system default!
        
        // This query assumes user timezone, but we're in system context
        var gr = new GlideRecord('incident');
        gr.addQuery('opened_at', '>=', this._getTodayInTimezone(userTimezone));
        gr.query();
        // Results will be inconsistent
    }
};

// RIGHT: Check execution context
var ScheduledScript = Class.create();
ScheduledScript.prototype = {
    execute: function() {
        if (gs.getUser().getID() === '6816f79cc0a8016401c5a33be04be441') { // guest user = system
            // Use system timezone or iterate through user preferences
            this._processSystemContext();
        } else {
            // Safe to use session timezone
            this._processUserContext();
        }
    }
};

Session data reflects the execution context, not necessarily user preferences. Always verify whether you're running in user or system context before relying on session values.

Gotchas

The session object always exists but may contain system default values rather than user preferences when called from scheduled jobs or system processes.

Session properties persist only for the current session and are lost when the user logs out or the session times out.

Impersonation changes the user context but does not change the session context—session data still reflects the original user's session.

Client IP address may show proxy or load balancer IPs rather than the actual user's IP in clustered environments.

Session language and timezone settings can be overridden by user preferences, so always validate these values before using them for critical formatting operations.

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