CAD Guide

Scoped Applications in ServiceNow

Introduction

ServiceNow's application scoping model is what enables the platform to host thousands of customizations — from small departmental tools to enterprise-grade applications — without configurations from one app interfering with another. Understanding scoping is essential for any developer building anything beyond simple one-off scripts.

What Is a Scope?

Every configuration element in ServiceNow belongs to a scope — either global or a named application scope. The scope:

Namespaces all table names, script names, and system properties
Controls which other applications can read or call your code
Determines where configurations can be deployed
Enables packaging for the ServiceNow App Store (Store apps must be scoped)

Global vs. Scoped Scope

Feature	Global	Scoped App
Table naming	No prefix	`x_[vendor]_[app]_table_name`
Can access all tables	✅ Yes	Only explicitly allowed
Can call any Script Include	✅ Yes	Only with cross-scope access
Affects all apps if broken	✅ Risk	❌ Isolated
Distributable on App Store	❌ No	✅ Yes
Recommended for new work	❌ Legacy	✅ Yes

Key principle: Global scope changes can break anything. Scoped changes can only break things within the scope boundary.

Creating a Scoped Application

System Applications > Studio > Create Application
— or —
System Applications > Applications > New

Application Definition Fields

Name: Human-readable application name
Scope: Auto-generated (e.g., x_acme_itsm_pro)
Version: Semantic versioning (1.0.0)
Vendor prefix: Your company's registered prefix (register at developer.servicenow.com)
Tables: Create application-specific tables here

Namespace Prefix

All artifacts in a scoped app are prefixed with the scope:

Scope: x_acme_myapp

Tables:          x_acme_myapp_config, x_acme_myapp_request
Script Includes: x_acme_myapp.MyHelper
System Properties: x_acme_myapp.feature.enabled
Roles:           x_acme_myapp.user, x_acme_myapp.admin

This prevents naming collisions with any other application on the instance.

Cross-Scope Access

A scoped application cannot access another scope's artifacts unless explicitly permitted.

Calling a Global Script Include from Scoped Code

// In a Scoped Script Include calling a Global one:
// The global Script Include must have "Accessible from" = All application scopes
var result = new global.UtilityHelper().doSomething();
//           ↑ prefix global. to call across scope boundary

Allowing Cross-Scope Access

On the target Script Include:

Accessible from:
- This application scope only (default, most restrictive)
- All application scopes (any scope can call)
- Only specified scopes (named whitelist)

Accessing Tables Across Scopes

For a scoped app to read/write a table outside its scope, configure Application Cross-Scope Access records:

System Applications > Application Cross-Scope Access > New
- Calling application: x_acme_myapp
- Target table/Script Include: incident
- Operation: Read, Write, Create
- Status: Allowed

Application Files

In Studio, an application is composed of application files — all the artifacts that belong to it:

Tables and fields
Script Includes
Business Rules
Client Scripts
UI Policies, UI Actions
REST APIs
Notifications
Roles
Properties

When you deploy the application (via Update Set or source control), all application files travel together.

Studio: The Development Environment

System Applications > Studio

Studio provides:

File browser for all application artifacts
Built-in code editor
Source control integration (Git)
Application publishing to the Store or internal catalog
Diff view for comparing versions

For serious application development, Studio is far superior to navigating the platform directly.

Application Versioning and Deployment

Via Update Sets (Simple)

For internal applications deployed between instances:

Make changes in dev
Export Update Set containing all application files
Import and commit in target instance

Via Source Control (Recommended for teams)

Studio → Source Control → Link to Repository

Each commit captures all changed application files
Branch-based development workflows
Pull request reviews before merging to main
Automatic history and rollback via Git

Common Scoped App Mistakes

Mistake	Impact	Fix
Building in global scope "for simplicity"	Uncontrolled blast radius	Always create a scoped app for new functionality
No cross-scope access configured	Runtime errors when accessing shared tables	Add Application Cross-Scope Access records
Forgetting scope prefix in client scripts	Script calls wrong Script Include	Always use `global.ScriptName` for cross-scope calls
Not registering a vendor prefix	Scope naming conflicts with other customers' apps	Register at developer.servicenow.com

Best Practices

Register a vendor prefix before building your first app
Create a new scoped application for every distinct business capability
Use Studio for all development within a scoped app
Configure cross-scope access explicitly — don't set everything to global access
Version your application with semantic versioning
Use source control for any team-developed application
Document cross-scope dependencies in the application's README

Conclusion

Scoped applications are the right architecture for any ServiceNow development that will live beyond a quick one-off script. The namespace isolation prevents configuration drift, the cross-scope access model makes dependencies explicit, and Studio provides the tooling needed to develop and deploy confidently. Invest the setup time — scoped apps pay dividends in maintainability as your platform grows.