GlideSystem.getCurrentScopeName()

gs.getCurrentScopeName()→ string

intermediateTested on Xanadu

What It Does

The getCurrentScopeName() method returns the sys_id-based name of the application scope where the current script is executing. When running in global scope, it returns the literal string 'global'. This scope identification happens at runtime based on where the executing script record resides in the database.

ServiceNow determines the scope by examining the sys_scope field on the script record (Business Rule, Script Include, etc.). For scoped applications, this returns the application's scope name from the sys_app table's scope field. The scope name follows the pattern x_vendor_appname for custom applications.

The method always returns a non-null string value. Even when called from Background Scripts or other contexts that might seem ambiguous, it correctly identifies the execution scope. Background Scripts execute in global scope unless explicitly run within a scoped application's context through the Application Navigator.

Edge cases include cross-scope function calls where the scope remains that of the originating script, not the called function's scope. When a global Script Include calls a scoped Script Include, getCurrentScopeName() returns 'global' throughout the entire call stack. REST API scripts inherit the scope of the endpoint definition.

Related methods include gs.getCurrentApplicationId() which returns the sys_id of the current application, and gs.getApplicationName() which returns the human-readable application name. These three methods provide different perspectives on the same scope context.

When to Use This

Use getCurrentScopeName() when building reusable components that must behave differently based on their scope context. Common scenarios include conditional logging levels, scope-specific configuration lookups, and preventing cross-scope data contamination. Libraries designed for both global and scoped usage rely heavily on this method for context-aware behavior.

Avoid using this method for simple scope validation where gs.getCurrentApplicationId() would be more appropriate. If you need to check whether you're in a specific application regardless of version, use the application ID instead. Don't use this for user permission checks—that's what ACLs and gs.hasRole() are for.

Common misuse includes hardcoding scope name comparisons that break when applications are renamed or cloned. Instead of checking for exact scope matches, consider using pattern matching or storing scope configurations in system properties that can be updated without code changes.

Return Value

Returns a string containing the current scope name. For global scope, this is always the literal string 'global'. For scoped applications, returns the scope identifier in the format x_vendor_appname where vendor is the publishing company namespace and appname is the application identifier. Store applications follow the same pattern.

The method never returns null, undefined, or empty string. It always provides a valid scope identifier that can be safely used in string operations, database queries, or logging without null checks. The returned string is safe for use in GlideRecord queries and URL parameters without additional encoding.

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 executed—the scope is cached in the execution context for performance
No audit records, Business Rules, or notifications are triggered by this read-only operation
Executes instantly with no measurable performance impact—safe for use in loops and frequent calls
Returns the same value throughout the entire script execution lifecycle, including before/after Business Rules
Works identically in all server-side contexts: Business Rules, Script Includes, Scheduled Jobs, and REST endpoints
Not affected by user session state, impersonation, or elevated privileges—reflects only the script's scope
Maintains consistent behavior during application installation, upgrade, and rollback processes

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 scope detection and loggingbasic

// Business Rule or Script Include that behaves differently per scope
var currentScope = gs.getCurrentScopeName();

// Log with scope-aware prefixes for easier filtering
if (currentScope == 'global') {
    gs.info('GLOBAL: Processing incident ' + current.number);
    // Global-specific logic here
    processGlobalIncident();
} else {
    gs.info('[' + currentScope + '] Processing incident ' + current.number);
    // Scoped application logic here
    processScopedIncident();
}

// Store scope for use in other functions
this.executionScope = currentScope;
gs.debug('Initialized in scope: ' + this.executionScope);

Demonstrates basic scope detection with conditional logic and scope-aware logging. The scope name becomes part of the log prefix for easier filtering in system logs.

Scope-specific configuration lookupintermediate

// Script Include that loads different configurations per scope
var ConfigManager = Class.create();
ConfigManager.prototype = {
    initialize: function() {
        this.currentScope = gs.getCurrentScopeName();
        this.loadScopeConfig();
    },
    
    loadScopeConfig: function() {
        var gr = new GlideRecord('sys_properties');
        
        if (this.currentScope == 'global') {
            // Load global configuration
            gr.addQuery('name', 'my_app.global.timeout');
        } else {
            // Load scope-specific configuration with fallback
            gr.addQuery('name', 'my_app.' + this.currentScope + '.timeout');
        }
        
        gr.query();
        this.timeout = gr.next() ? gr.getValue('value') : '30000';
        
        gs.debug('Loaded timeout config for ' + this.currentScope + ': ' + this.timeout);
    },
    
    getTimeout: function() {
        return parseInt(this.timeout);
    }
};

Shows how to build scope-aware configuration management. Each scope can have its own settings while maintaining a consistent API across all scopes.

The classic mistake: hardcoded scope comparisonadvanced

// WRONG: Hardcoded scope names break during cloning/renaming
var scope = gs.getCurrentScopeName();
if (scope == 'x_mycomp_myapp') {
    // This breaks when the app is cloned or renamed
    processMyAppLogic();
}

// RIGHT: Pattern matching or property-based configuration
var scope = gs.getCurrentScopeName();
var isMyCompanyApp = scope.indexOf('x_mycomp_') === 0;
if (isMyCompanyApp && scope != 'global') {
    processMyAppLogic();
}

// BETTER: Use system properties for scope configuration
var enabledScopes = gs.getProperty('my_integration.enabled_scopes', 'global');
var scopeList = enabledScopes.split(',');
if (scopeList.indexOf(scope) >= 0) {
    processMyAppLogic();
}

Hardcoded scope comparisons fail when applications are cloned or renamed. Use pattern matching or configurable scope lists to build resilient scope-aware code.

Gotchas

Cross-scope function calls maintain the originating script's scope—calling a scoped Script Include from global code still returns 'global' throughout the entire call stack.

REST API endpoints inherit the scope of the endpoint definition, not the scope of any Script Includes they might call during processing.

Background Scripts execute in global scope unless explicitly run through a scoped application's context in the Application Navigator.

The scope name can change when applications are cloned, renamed, or moved between instances—avoid hardcoded string comparisons in production code.

Scheduled Jobs always execute in the scope where the job record was created, even if the underlying Script Include exists in a different scope.

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