ServiceNow Application Scope

Application Scope is the namespace and security boundary that separates one application's code and configuration from another's on the same ServiceNow instance. Every configuration artifact — tables, scripts, workflows, and catalog items — belongs to a scope. Scopes prevent different applications from accidentally overwriting each other's work and are mandatory for any app published to the ServiceNow App Store.

Why Scope Exists

Before application scope, all customizations on a ServiceNow instance lived in one shared global space. A Script Include named "Utils" in one integration could conflict with a Script Include named "Utils" in a different integration. Upgrades sometimes overwrote custom code. Determining which application owned which configuration was impossible without documentation.

WITHOUT Scope (Global):
  utils.js (from Integration A)
  utils.js (from Integration B)  ← CONFLICT! Which one survives?
  business_rule_x (who owns this? unknown)

WITH Scope:
  x_acme_integration_a.Utils        ← Clearly owned by Integration A
  x_acme_integration_b.Utils        ← Clearly owned by Integration B
  x_acme_integration_a.business_rule_x ← Owned and protected

The Global Scope

The Global scope (also called the baseline or default scope) is where all of ServiceNow's built-in applications live. Custom configurations made without creating an explicit application scope also land in the Global scope. Administrators working in Global scope can access and modify any table and record in the instance — but this openness makes maintenance harder and creates risk of conflicts.

Custom Application Scopes

When a developer creates a new application in Studio or via System Applications > Applications, ServiceNow creates a dedicated scope for it. The scope name follows the pattern: x_<vendor_prefix>_<app_name>.

Scope Name Structure:
x   = custom (not from ServiceNow)
acme = your company's 4-letter prefix (registered with ServiceNow)
hr_onboard = the application's short name

Full scope: x_acme_hr_onboard

All artifacts in this app:
  x_acme_hr_onboard.OnboardingUtils    (Script Include)
  x_acme_hr_onboard.u_onboarding_task  (Custom Table)
  x_acme_hr_onboard.new_hire_flow      (Flow)

Scope Access Controls

Scoped applications protect their own artifacts from modification by other scopes. When a script in Scope A tries to read or write a record in a table owned by Scope B, Scope B's access settings determine whether it is allowed. Each scoped table has an "Accessible from" setting:

• This application scope only: Only scripts within the same scope can access this table.
• All application scopes: Any scope can access this table.

Cross-Scope Calls

When a script in one scope needs to call code in another scope, the target scope must explicitly allow cross-scope access. The receiving Script Include must mark itself as "Accessible from all scopes." Without this permission, the call is blocked with a security error — even if both scopes are in the same instance.

Scope A Script → calls → Scope B Script Include
                                   ↓
               Is "Accessible from" = All scopes?
                    Yes → Call succeeds
                    No  → Security error, call blocked

The Application Picker

The application picker appears in the top right of the ServiceNow header when a user has the admin role. It shows which scope is currently active. All configuration changes made while a scope is active are assigned to that scope. Switching to a different scope in the picker immediately redirects new configurations to the new scope.

Application Picker:
[ Global ]           ← Active scope shown here
[ Switch application... ]
    → Global
    → HR Onboarding (x_acme_hr_onboard)
    → IT Automation  (x_acme_it_auto)

Scoped vs. Global Business Rules

A Business Rule created while the Global scope is active applies to its table globally — any user's interaction with that table triggers it. A Business Rule created while a custom scope is active belongs to that application. If the application is deactivated, the Business Rule stops firing. Scope ownership makes cleaning up decommissioned applications reliable and complete.

Publishing Scoped Applications to the App Store

The ServiceNow App Store (ServiceNow Store) requires all submitted applications to use a dedicated scope. This ensures that installing a store app does not interfere with the customer's existing customizations. Scoped applications install cleanly, can be removed cleanly, and upgrade through ServiceNow's managed update mechanism without touching anything outside their scope boundary.

Checking the Current Scope in Scripts

Developers check the current application scope in scripts using:

gs.getCurrentApplicationScope();   // Returns the scope name string
// Example output: "x_acme_hr_onboard"

gs.getProperty('glide.appcreator.company.code');  // Returns the vendor prefix