Global Scope

What It Is

Global Scope is ServiceNow's default application scope that provides unrestricted access to all platform tables, APIs, and system resources. Every script, business rule, script include, and customization created without an explicit application scope automatically runs in Global Scope. This scope bypasses all cross-scope security restrictions that normally prevent applications from accessing each other's data and functionality. Global Scope exists as the foundational execution context where ServiceNow's core platform logic operates, and where most pre-scoped application era customizations continue to live.

Architecturally, Global Scope sits at the platform layer rather than belonging to any specific application. It exists outside the application scope framework introduced in Fuji, predating the scoped application model entirely. While scoped applications are contained within the sys_app table with defined boundaries, Global Scope operates as the platform's native execution environment. Studio shows Global Scope as a special application with the identifier global, but this is more of a convenience representation than a true application container.

Global Scope relates directly to ServiceNow's script execution engine and security model. When a script executes in Global Scope, the platform grants it access to any table regardless of application scope restrictions, cross-scope access controls, or application-specific security policies. The underlying execution environment treats Global Scope scripts as platform-level code with elevated privileges similar to ServiceNow's own internal scripts. This means Global Scope scripts can read from and write to scoped application tables, call private script includes from other applications, and access protected APIs that scoped applications cannot reach without explicit access policies.

You cannot function without Global Scope in several critical scenarios. Legacy customizations created before Fuji exist exclusively in Global Scope and cannot be moved without significant refactoring, making Global Scope essential for maintaining existing functionality during platform upgrades. Cross-application integration scripts that need to read or write data across multiple scoped applications require Global Scope privileges to bypass cross-scope security restrictions. Platform-level utility scripts, system maintenance scripts, and administrative automations that operate on core ServiceNow tables like sys_user, cmdb_ci, and incident often require Global Scope access to function effectively across the entire platform.

Platform owners and senior architects typically manage Global Scope strategy and governance, while system administrators handle day-to-day Global Scope customizations and maintenance. Developers working in Global Scope need elevated privileges since their scripts can impact any part of the platform, making code review and testing more critical than with scoped applications. The relationship between admins and Global Scope is fundamentally different from scoped applications because Global Scope changes can affect functionality across the entire instance, requiring broader impact analysis and more comprehensive testing before deployment.

Recent ServiceNow releases have not changed Global Scope behavior significantly, but Vancouver and later versions have strengthened the boundaries between Global Scope and scoped applications. Vancouver introduced stricter cross-scope access policies that affect how Global Scope scripts interact with scoped application private methods and protected tables. Xanadu enhanced the Application Portfolio Management capabilities that help track Global Scope customizations and their relationships to scoped applications, making it easier to identify candidates for scope migration during application modernization projects.

Where to Find and Configure It

Access Global Scope through System Applications > Studio and select Global from the application picker to view and create Global Scope customizations. Navigate to System Definition > Business Rules and filter by Application equals Global to see all Global Scope business rules. View Global Scope script includes at System Definition > Script Includes with the same application filter.

Check current scope context in System Applications > Applications where Global appears as a special entry with Scope value global for tracking purposes. Background scripts run in Global Scope when accessed through System Definition > Scripts - Background unless explicitly wrapped in a scoped application context. Global Scope customizations appear throughout configuration tables like sys_script, sys_script_include, and sys_ui_script with sys_scope field pointing to the global scope record.

How It Works Step by Step

Global Scope operates at the script execution engine level, where ServiceNow's JavaScript processor evaluates each script's scope context before granting access to platform resources. When a script executes, the platform checks the sys_scope field on the script record to determine execution privileges and security boundaries. Global Scope scripts bypass the Application Access Management framework entirely, receiving direct access to all tables, APIs, and system functions without cross-scope validation or access policy enforcement.

The scope inheritance model treats Global Scope as the root execution context that can access any application scope while scoped applications cannot access Global Scope private methods without explicit access policies. This asymmetrical relationship means Global Scope scripts can call scoped application script includes, read scoped application tables, and modify scoped application data without restriction. Caching behavior for Global Scope follows the same patterns as scoped applications, but Global Scope scripts can invalidate caches across all applications, making them more powerful but potentially more disruptive to platform performance.

The Execution Order

1. Platform receives script execution request and retrieves the script record from configuration tables
2. Script execution engine reads the sys_scope field to determine execution context and security boundaries
3. For Global Scope scripts, platform skips cross-scope access validation and application boundary checks
4. JavaScript engine initializes global namespace with unrestricted access to all platform APIs and tables
5. Script executes with elevated privileges, able to read/write any table and call any API
6. Platform logs execution details to syslog and sys_script_execution_history with global scope context

// Global Scope business rule accessing multiple applications
(function executeRule(current, previous /*null when async*/) {
    
    // Access scoped application table without restrictions
    var scopedGR = new GlideRecord('x_custom_app_request');
    scopedGR.query();
    
    // Call script include from different scoped application
    var utilityClass = new global.ScopedUtilityClass();
    var result = utilityClass.processRequest(current);
    
    // Modify core platform table
    var userGR = new GlideRecord('sys_user');
    userGR.get(current.caller_id);
    userGR.setValue('u_last_incident', current.getUniqueValue());
    userGR.update();
    
    // Access another scoped application's private method
    var privateAPI = new sn_integration_app.PrivateIntegrationAPI();
    privateAPI.syncExternalData(current);
    
})(current, previous);

Real-World Scenarios

Cross-Application Data Synchronization

Your organization uses multiple scoped applications for different business functions, but needs a master synchronization process that updates user preferences across all applications when someone changes their profile. The sync process must read from HR application tables, update ITSM application preferences, and modify custom application settings without individual cross-scope access policies.

// Global Scope script include for cross-application user sync
var UserPreferenceSync = Class.create();
UserPreferenceSync.prototype = {
    
    syncUserAcrossApps: function(userSysId) {
        var user = new GlideRecord('sys_user');
        if (!user.get(userSysId)) return false;
        
        // Read from HR application
        var hrProfile = new GlideRecord('x_hr_app_employee_profile');
        hrProfile.addQuery('user', userSysId);
        hrProfile.query();
        
        if (hrProfile.next()) {
            // Update ITSM application preferences
            var itsmPref = new GlideRecord('x_itsm_app_user_preference');
            itsmPref.addQuery('user', userSysId);
            itsmPref.query();
            
            while (itsmPref.next()) {
                itsmPref.setValue('department', hrProfile.getValue('department'));
                itsmPref.setValue('location', hrProfile.getValue('location'));
                itsmPref.update();
            }
            
            // Update custom application settings
            this._updateCustomAppSettings(userSysId, hrProfile);
        }
        return true;
    },
    
    _updateCustomAppSettings: function(userSysId, hrProfile) {
        // Private method accessible across all scopes
    },
    
    type: 'UserPreferenceSync'
};

Create this as a script include in Global Scope through Studio > Global > Script Includes with Accessible from set to All application scopes. Watch for transaction timeouts when processing large user sets, and ensure the calling scoped applications handle the Global Scope response properly. Test cross-scope access thoroughly since Global Scope changes can affect multiple applications simultaneously, requiring comprehensive regression testing across all integrated applications.

Legacy Integration Business Rule Migration

A critical business rule created before Fuji handles incident escalation by updating multiple related tables including problem, change, and knowledge base records. This legacy rule must remain in Global Scope because it accesses tables from different scoped applications that don't have cross-scope access policies configured.

// Global Scope business rule on incident table
(function executeRule(current, previous) {
    
    // Only execute on state change to escalated
    if (current.state != 6 || previous.state == 6) return;
    
    // Update related problem record (Problem Management app)
    if (!gs.nil(current.problem_id)) {
        var problemGR = new GlideRecord('problem');
        problemGR.get(current.problem_id);
        problemGR.setValue('state', 'Escalated');
        problemGR.setValue('escalated_incident', current.getUniqueValue());
        problemGR.update();
    }
    
    // Create emergency change (Change Management scoped app)
    var changeGR = new GlideRecord('x_change_mgmt_emergency_change');
    changeGR.initialize();
    changeGR.setValue('source_incident', current.getUniqueValue());
    changeGR.setValue('short_description', 'Emergency change for ' + current.number);
    changeGR.setValue('state', 'Open');
    var changeSysId = changeGR.insert();
    
    // Update knowledge base statistics (Knowledge Management app)
    var kbStats = new GlideRecord('x_knowledge_app_escalation_stats');
    kbStats.addQuery('category', current.category);
    kbStats.query();
    if (kbStats.next()) {
        kbStats.setValue('escalation_count', parseInt(kbStats.getValue('escalation_count')) + 1);
        kbStats.update();
    }
    
})(current, previous);

Keep this business rule in Global Scope and configure it through System Definition > Business Rules with Table set to Incident [incident] and When set to before update. Monitor execution performance since Global Scope rules can impact system performance more broadly than scoped rules, and document all table dependencies for future migration planning. Consider breaking this into smaller, scoped application-specific rules with proper cross-scope access policies for long-term maintainability.

System Administrative Automation Script

Your platform team needs an automated cleanup script that runs nightly to purge old records, reset test data, and maintain system performance across all applications. This script must access core platform tables, scoped application tables, and system configuration records without scope restrictions.

// Global Scope scheduled script job
(function() {
    
    var cleanupLog = new GSLog('SystemCleanup', 'SystemMaintenance');
    var recordsDeleted = 0;
    
    // Clean up old syslog entries (core platform table)
    var syslogGR = new GlideRecord('syslog');
    syslogGR.addQuery('sys_created_on', '<', gs.daysAgoStart(30));
    syslogGR.addQuery('level', 'NOT IN', 'error,fatal');
    syslogGR.query();
    while (syslogGR.next()) {
        syslogGR.deleteRecord();
        recordsDeleted++;
    }
    
    // Clean up test data from scoped applications
    var testAppTables = ['x_test_app_sample_data', 'x_demo_app_temp_records'];
    testAppTables.forEach(function(tableName) {
        var testGR = new GlideRecord(tableName);
        testGR.addQuery('u_test_record', true);
        testGR.addQuery('sys_created_on', '<', gs.daysAgoStart(7));
        testGR.query();
        while (testGR.next()) {
            testGR.deleteRecord();
            recordsDeleted++;
        }
    });
    
    // Reset system properties for nightly batch processing
    gs.setProperty('system.batch.processing.enabled', 'true');
    gs.setProperty('system.maintenance.last_run', gs.nowDateTime());
    
    cleanupLog.info('System cleanup completed: ' + recordsDeleted + ' records deleted');
    
})();

The Classic Mistake

// Business Rule created in Global scope
// Name: Update Incident Priority
// Table: incident
// When: before
// Condition: priority.changed()

(function executeRule(current, previous /*null when async*/) {
    
    // Custom logic for priority escalation
    if (current.priority <= 2 && current.state != 6) {
        current.assignment_group = '287ebd7da9fe198100f92cc8d1d2154e';
        current.assigned_to = '';
        gs.eventQueue('incident.priority.escalated', current, 
                      gs.getUserID(), gs.getUserName());
    }
    
})(current, previous);

This approach creates immediate technical debt and breaks ServiceNow's application lifecycle management. The customization becomes invisible to Update Set tracking by default, making it nearly impossible to migrate between instances reliably. When other scoped applications try to extend or override this behavior, they encounter unpredictable precedence conflicts because Global scope executes with different timing than scoped applications. The business rule appears to work perfectly in development but creates deployment nightmares and makes future integrations fragile.

// Business Rule in custom scoped app 'x_acme_escalation'
// Name: Update Incident Priority
// Table: incident
// When: before
// Condition: priority.changed()

(function executeRule(current, previous /*null when async*/) {
    
    var EscalationUtil = x_acme_escalation.EscalationUtil;
    
    if (current.priority <= 2 && current.state != 6) {
        var result = EscalationUtil.assignToTier2Support(current);
        if (result.success) {
            gs.eventQueue('x_acme_escalation.priority.escalated', 
                         current, gs.getUserID(), gs.getUserName());
        }
    }
    
})(current, previous);

When to Use This vs Alternatives

Global scope should only be used for emergency fixes, debugging existing legacy customizations, and accessing cross-application data that scoped applications cannot reach. It's the last resort when proper scoped development isn't feasible due to time constraints or technical limitations.

Use Global Scope When

You need to modify core ServiceNow tables that scoped applications cannot access, such as sys_user_group or sys_user_role with complex cross-table queries. You're performing emergency production fixes where creating a scoped application would take too long and risk additional downtime. You need to debug or temporarily override existing Global scope customizations that can't be easily moved to a scoped application without breaking dependencies.

Use Scoped Applications Instead When

You're building any new functionality, integrations, or business logic — scoped applications provide proper version control, dependency management, and deployment tracking. You need to share customizations with other ServiceNow instances or plan to publish to the ServiceNow Store. You want predictable upgrade behavior and the ability to disable or remove functionality cleanly without affecting other customizations.

Use Both Global and Scoped Together When

You're migrating legacy Global customizations to scoped applications gradually — create new scoped functionality while maintaining Global scope for existing integrations that can't be moved immediately. You need scoped applications to call Global scope Script Includes for shared utility functions that multiple applications require. You're building APIs or web services that need to aggregate data across multiple scoped applications where individual scopes lack sufficient cross-application visibility.

Platform Interactions & Side Effects

• Business Rules in Global scope execute before scoped application Business Rules, potentially overriding scoped application logic unexpectedly
• ACLs created in Global scope are not tracked in Update Sets by default unless Track Global ACLs in Update Sets system property is enabled
• Script Includes in Global scope can be called by any scoped application, but scoped Script Includes cannot be called from Global scope without explicit API exposure
• Notifications created in Global scope bypass scoped application email templates and use Global scope variables exclusively
• UI Actions in Global scope appear on all forms regardless of scoped application context and can interfere with scoped application UI customizations
• Transform Maps in Global scope can process data destined for scoped application tables but cannot use scoped application Script Includes for data transformation
• Flow Designer actions in Global scope have unrestricted table access but create audit records in sys_flow_context without application attribution
• Client Scripts in Global scope execute on all forms and can cause performance issues by running unnecessary code on scoped application pages
• REST API endpoints defined in Global scope bypass scoped application security models and authenticate using Global scope ACLs exclusively
• Scheduled Jobs running in Global scope can access and modify data in any scoped application but write execution logs to syslog table without scope attribution

Debugging and Troubleshooting

The most common failure symptoms involve scope precedence conflicts where Global scope customizations override scoped application behavior unexpectedly. Users report that new scoped application features don't work as expected, while administrators see intermittent behavior where the same action produces different results. Business Rules may appear to fire twice, UI Actions may not appear, or ACLs may grant unexpected access because Global scope logic executes with higher precedence than scoped application logic.

For debugging scope conflicts, examine System Log > All for script execution patterns and use the Business Rule > Debug Business Rules module to trace execution order. Check sys_metadata table to identify which customizations exist in Global scope versus scoped applications. The sys_scope field in most configuration tables reveals the scope ownership of problematic customizations.

Common error messages include "Access denied" when scoped applications try to call Global Script Includes, "Undefined function" errors when Global scope tries to access scoped functions, and "Variable is not defined" when scripts reference variables from different scopes. Update Set preview errors often show "No update set specified" for Global scope changes, indicating tracking configuration issues.

Diagnostic Checklist:

• Query sys_script table with condition sys_scope=global to identify all Global scope Business Rules affecting the problematic table
• Check System Definition > Execution Order to verify Business Rule precedence between Global and scoped applications
• Enable glide.script.log.level=debug system property temporarily to capture detailed script execution logs
• Review sys_update_set_member table to confirm whether Global scope changes are being tracked in Update Sets
• Use gs.getScope() in server scripts to confirm the actual execution scope context during runtime
• Examine ACL evaluation using Security Debug module to identify Global scope ACL conflicts with scoped application security
• Validate Update Set preview results for missing Global scope dependencies when importing scoped applications

Quick Reference

• Global scope Business Rules execute with order 100 by default, while scoped application Business Rules start at order 1000
• Global scope changes are excluded from Update Sets unless glide.update_set.track_global_changes system property is enabled
• The sn_app_rollback plugin cannot roll back Global scope customizations — only scoped application changes
• Global scope Script Includes cannot access scoped application Script Includes, but the reverse is possible with proper API exposure
• Application scopes are stored in sys_scope table with Global scope having sys_id global
• REST API endpoints in Global scope ignore scoped application authentication and use Global scope ACLs exclusively
• UI Policies in Global scope can override scoped application UI Policies regardless of order values or conditions
• Flow Designer flows in Global scope can call any Spoke action, while scoped flows are restricted to compatible scope actions
• Transform Maps in Global scope bypass Import Set table scope restrictions and can write to any table regardless of application boundaries
• Scheduled Jobs running in Global scope appear in sys_trigger table with sys_scope=global and cannot be managed by scoped application lifecycles