GlideSystem.isInteractive()

gs.isInteractive()→ boolean

intermediateTested on Xanadu

What It Does

The gs.isInteractive() method checks the execution context of the current thread to determine if it's running within an interactive user session. ServiceNow maintains context flags throughout the request lifecycle that distinguish between user-initiated actions and system-generated processes. When a user submits a form, clicks an Action Button, or loads a list view, ServiceNow sets internal flags indicating this is an interactive request where the user expects an immediate response.

Internally, ServiceNow tracks the request source through session attributes and thread-local variables. Interactive sessions include form submissions, UI Actions, Client Scripts making server calls, and Direct Web Services calls from the UI. The platform maintains this context even through multiple Business Rule executions, Script Include calls, and database operations that might occur during a single user transaction.

The method returns true for user-driven requests and false for background processes including Scheduled Jobs, Business Rule Engines processing email, REST API calls from external systems, Import Sets, Data Sources, and Transform Scripts. Notification generation, Workflow activities, and Flow executions also return false unless they were triggered by a direct user action.

Edge cases include situations where the context can change mid-execution. If an interactive Business Rule triggers a Script Include that makes a REST call to another ServiceNow instance, the gs.isInteractive() call in the original Business Rule returns true, but any server-side scripts executing on the remote instance would see false. The method also returns false during system startup, system clone operations, and when running through the ServiceNow CLI or developer tools.

This method is related to gs.isLoggedIn() but serves a different purpose. While gs.isLoggedIn() checks if there's an authenticated user session, gs.isInteractive() specifically identifies whether that user is actively waiting for a response. A scheduled job running as a specific user would have gs.isLoggedIn() return true but gs.isInteractive() would return false.

When to Use This

Use gs.isInteractive() when you need different behavior based on whether a user is actively waiting for the operation to complete. This is particularly valuable in Business Rules where you want to perform expensive operations (like complex calculations or external system calls) only during background processing, while keeping user-facing transactions fast and responsive. Common use cases include conditional logging (verbose logging for background jobs, minimal logging for interactive requests), different validation rules (strict validation for user input, automated cleanup for batch operations), and performance optimizations.

Avoid using this method when you really need to check authentication status (use gs.isLoggedIn() instead) or user roles (use gs.hasRole()). Don't use it as a substitute for proper ACL implementation or as a way to bypass security controls. The method is also not appropriate for determining whether to show or hide UI elements — Client Scripts and UI Policies handle that better since they run on the actual user interface.

A common misuse pattern is developers who think gs.isInteractive() can distinguish between manual record updates versus automated updates. This fails because REST API calls from legitimate integrations return false, but so do legitimate system processes like Workflow. If you need to track the true source of changes, implement proper audit trails using gs.getSession() and session attributes, or use Business Rule conditions based on gs.getUserName() and specific integration users.

Return Value

The method returns a Boolean value: true for interactive user sessions, false for background or automated processes. The method never returns null or undefined — it always provides a definitive boolean result based on the current execution context. There are no failure conditions for this method since it's simply reading internal platform state.

The return value is safe to use directly in conditional statements without null checking or type conversion. Since JavaScript treats true and false as proper boolean values, you can use it in logical operations, ternary expressions, and compound conditions without additional safeguards.

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 operations are performed — this method reads from in-memory session context only
Execution is extremely fast with no caching needed since it accesses thread-local variables
The same value persists throughout the entire request lifecycle, including all Business Rule phases (before, after, async)
Script Includes called from Business Rules inherit the same interactive state as the triggering Business Rule
No audit entries, workflow triggers, or notifications are generated by calling this method
ACL evaluation is not triggered since this method only reads system context, not user data
The result remains consistent even when Business Rules create or update other records during the same transaction

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

Performance optimization in Business Rulesbasic

// Before Business Rule on incident table
(function executeRule(current, previous /*null when async*/) {
    
    if (gs.isInteractive()) {
        // User is waiting - keep it fast
        gs.info('Incident ' + current.number + ' updated by ' + gs.getUserName());
        
        // Skip expensive operations for now
        if (current.state.changesTo('6')) { // Resolved
            current.work_notes = 'Resolution logged at ' + gs.nowDateTime();
        }
        
    } else {
        // Background processing - we can afford to be thorough  
        gs.debug('Full audit: ' + current.number + ' - Previous state: ' + previous.state + 
                ' New state: ' + current.state + ' Updated: ' + current.sys_updated_on);
        
        // Expensive LDAP lookup for user details
        var userGR = new GlideRecord('sys_user');
        userGR.get(current.assigned_to);
        if (userGR.isValidRecord()) {
            current.work_notes += '\nAssigned to: ' + userGR.name + ' (' + userGR.email + ')';
        }
    }
    
})(current, previous);

Interactive requests get minimal logging and simple timestamp updates, while background jobs perform comprehensive audit logging and expensive user lookups without impacting user experience.

Conditional validation with different rulesintermediate

// Before Business Rule on sc_req_item table
(function executeRule(current, previous) {
    
    // Always validate basic fields
    if (!current.cat_item.nil() && !current.quantity) {
        gs.addErrorMessage('Quantity is required for catalog items');
        current.setAbortAction(true);
        return;
    }
    
    if (gs.isInteractive()) {
        // Strict validation for user input - prevent common mistakes
        if (current.quantity > 100) {
            gs.addErrorMessage('Quantity cannot exceed 100. For bulk orders, contact procurement.');
            current.setAbortAction(true);
        }
        
        // Verify budget in real-time for user requests
        var budgetUtil = new BudgetValidationUtil();
        if (!budgetUtil.validateUserBudget(current.requested_for, current.price * current.quantity)) {
            gs.addErrorMessage('Insufficient budget for this request');
            current.setAbortAction(true);
        }
        
    } else {
        // Relaxed validation for automated processes (imports, integrations)
        if (current.quantity > 1000) {
            gs.warn('Large quantity detected: ' + current.quantity + ' for item ' + current.cat_item.getDisplayValue());
            // Log but don't block - may be legitimate bulk provisioning
        }
    }
    
})(current, previous);

User-driven requests enforce strict business rules and budget checks, while automated processes use relaxed validation to accommodate bulk operations and system integrations.

The classic mistake — confusing session typesadvanced

// WRONG: Trying to use isInteractive() for security
(function executeRule(current, previous) {
    
    // This fails! REST API calls return false but may be legitimate
    if (!gs.isInteractive()) {
        gs.addErrorMessage('Only interactive users can update this record');
        current.setAbortAction(true);
        return;
    }
    
})(current, previous);

// RIGHT: Use proper authentication and authorization
(function executeRule(current, previous) {
    
    // Check if user has the right role, regardless of session type
    if (!gs.hasRole('incident_manager') && !gs.hasRole('admin')) {
        gs.addErrorMessage('Insufficient privileges to modify critical incidents');
        current.setAbortAction(true);
        return;
    }
    
    // THEN use isInteractive() for workflow optimization
    if (gs.isInteractive()) {
        // Immediate user feedback
        gs.addInfoMessage('Critical incident updated. Notifications will be sent.');
    } else {
        // Background processing - detailed logging
        gs.eventQueue('incident.critical.updated', current, gs.getUserName());
    }
    
})(current, previous);

The first example incorrectly blocks legitimate API calls and automated processes. The correct approach uses role-based security first, then applies isInteractive() for user experience optimization only.

Gotchas

REST API calls from ServiceNow Mobile Apps return false even though a user initiated the request, because they go through the REST infrastructure.

Scheduled Jobs that run Script Includes return false even if those Script Includes normally run in interactive contexts during regular business hours.

Transform Scripts during Import Set processing always return false, even when the import was manually triggered by a user through the UI.

Business Rules triggered by Workflow activities return false because Workflow execution is considered a background process, even if the workflow was started interactively.

The value remains consistent throughout the entire transaction, so async Business Rules see the same result as the original before/after Business Rules that triggered them.

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