Scoped Applications in ServiceNow: Why They Matter and How to Work with Them

// In global scope — this FAILS if the Script Include is scope-restricted
var myUtil = new x_nowspec_myapp.MyUtil();

// Works only if MyUtil has "Accessible from: All application scopes"

Scoped app table design

Tables created inside a scoped application automatically get the application's prefix — x_myapp_ — prepended to the table name. This namespacing prevents conflicts with tables in other scopes and makes it clear which application owns each table. Design your table hierarchy carefully before creating tables: extending the Task table for workflow-driven records gives you inherited fields (number, assigned_to, state, work_notes) and integration with ITSM processes at the cost of sharing the Task table's performance characteristics. Creating standalone tables is simpler but requires building workflow and notification infrastructure from scratch. For most business application tables, extending Task is the right choice; for reference data and lookup tables, standalone is cleaner.

Application scope and the developer PDI

When developing a scoped application on your Personal Developer Instance, set the Application Scope to your application (not Global) before creating any configuration. Everything created while your scope is set is automatically associated with your application. Switching back to Global accidentally while creating artifacts is a common mistake — it puts global records in your application that will need to be moved or recreated. Check the application picker (top-right of the Navigator) before creating any new records during development. See the Update Sets guide for how scoped application changes are captured and deployed.

Scope Isolation in Practice

When you create a scoped application, ServiceNow creates a namespace — typically formatted as x_companyabbr_appname — that prefixes every artifact belonging to that app. Tables, Script Includes, Business Rules, UI Actions, and system properties all carry this prefix. This isolation means your app's Script Include named Utils becomes x_myco_myapp.Utils and cannot accidentally conflict with a global Utils Script Include or another app's utility class. Understanding this prefix system is essential before you start building, because renaming or changing the scope prefix after development is extremely disruptive — it requires updating every cross-reference manually.

Cross-Scope Script Access

Scoped applications can call global scope APIs, but global scripts cannot call scoped APIs by default. To expose a scoped Script Include for consumption by other scopes or global scripts, you must set its "Accessible from" property to "All application scopes." Similarly, tables in a scoped app have access controls at the scope level — a table marked as accessible only within its own scope cannot be queried by scripts running in a different scope. This matters when building integrations: if an IntegrationHub spoke running in the global scope needs to read data from your scoped app's table, you must explicitly configure that access. The ACL guide covers the access model in depth.

Application Files and Update Sets

Files belonging to a scoped application are tracked differently from global customisations. When you are working inside an app in the Studio, changes are automatically associated with the application rather than the active Update Set. This is one of the key workflow differences from global development — you publish and deploy scoped app changes through the Application Repository (or ServiceNow Store for commercial apps), not through the Update Set mechanism. For in-house scoped apps being promoted from dev to test to production, the standard workflow is to publish the app to the Application Repository from development and install it in each downstream instance.

Private Tables and Data Separation

Scoped apps can define tables with scope-level access restrictions that prevent other applications from reading or writing data even if ACLs would otherwise permit it. This is the technical foundation for building SaaS-style multi-tenant applications on ServiceNow — each customer's data can be stored in a scoped table with access rules enforced at the scope boundary rather than purely through ACLs. For enterprise applications, this isolation also simplifies audit and compliance work: you can demonstrate that application X's data is not accessible to application Y's scripts with a clear, enforceable technical control rather than a policy-level claim.

Scripted REST APIs in Scoped Apps

When you build a Scripted REST API inside a scoped application, the API namespace reflects the scope. The base path of the API is prefixed with your scope identifier, which affects the URL structure and must be accounted for in any external system calling the API. Scoped Scripted REST APIs have the same capabilities as global ones — they can call other scoped Script Includes, query scoped tables, and interact with the full platform API — but the scope context means that cross-scope calls follow the same access rules as any other cross-scope script interaction. Test these access boundaries explicitly in development before assuming your API handler can read from tables in a different scope.

Dependency Management

Scoped applications can declare dependencies on other scoped applications through the Application Dependencies module in Studio. This creates an explicit, version-aware dependency graph: if your app requires version 2.1 of a shared utility app, the platform enforces that requirement at install time. Managing dependencies explicitly prevents the silent failure mode where your app's functionality degrades because a dependency was updated or removed. For teams building multiple interdependent scoped apps, maintaining a clear dependency graph and testing dependency combinations as part of the Instance Scan process reduces integration surprises in production.

Versioning and Release Management

Scoped applications have built-in version management through the Application Version field. When you publish a new version, the version number increments and the release appears in the Application Repository. Downstream instances install specific versions, giving you control over which release each environment runs. This version pinning is particularly valuable for applications used by multiple customers or teams — you can release a new version without forcing all consumers to upgrade immediately. The tradeoff is that you must actively manage compatibility: when a new version changes a Script Include API or table structure that other applications depend on, communicate the breaking change clearly and provide a migration window. The Update Sets mechanism does not version in this way — Update Sets are one-directional and cannot be rolled back cleanly, which is one of the core reasons scoped app development is preferred over global customisation for any reusable component.

Testing Scoped Applications

Testing a scoped application requires a different approach from testing global customisations. Because scoped app artifacts are associated with the app version rather than the active Update Set, test environments need the app installed (not just an Update Set committed) to reflect the development state accurately. Use the Studio's built-in test framework for unit tests on Script Includes — the Automated Test Framework (ATF) integrates with scoped apps and allows creating tests that exercise your app's API surface. Test cross-scope access explicitly: if your app exposes Script Includes to other scopes, write ATF tests that call those Script Includes from a different scope to verify the access configuration is correct. The debugging guide covers how to use the Script Debugger within a scoped app context, which has some differences from global debugging.