Please use for the latest documentation.

This site is for reference purposes only and may not be accurate for the latest ServiceNow version

Application Scope

From Wiki Archive
Jump to: navigation, search

Note: This article applies to Fuji. For more current information, see Application Scope at

The Wiki page is no longer being updated. Please refer to for the latest product documentation.


Each application has an application scope that determines which of its resources are available to other parts of the system. Application scoping ensures that one application does not impact another application. You can specify what parts of the application other applications can access by setting application access settings.

For example, suppose you create a conference room booking application in its own application scope. By default, the application can access and change its own tables and business logic but other applications such as incident management cannot make changes to it without explicit permission. The application scope ensures:

  • The conference room booking application does not interrupt core business services.
  • Other applications do not interfere with its normal functioning.

Application scope is available for new and upgraded instances starting with the Fuji release.

Available Application Scopes

All applications will have an application scope. The scope value can be one of two types:

  • Private application scope
  • Global scope

Private Application Scope

Applications in a private application scope restrict access to their application artifacts so that only application artifacts in the same scope have full access to create, modify, remove, or run application data. As the application developer, you set what parts of an application are accessible from other application scopes with application access settings.

By default, all new applications belong to their own application scope set to the application name, and they allow other applications to read their records with script calls. For example, a conference room booking application can have its own tables and business logic in the Conference Room Booking private application scope. While it can allow other applications to read its records such as a list of available conference rooms, it can prevent other applications from overwriting protected data such as reservation schedules.

Global Scope

Applications in the global scope are like shared resources that any application developer can modify. Global scope applications do not have a unique namespace identifier included in their application artifact names, but they can have their own application access permissions. Typically, only applications provided by ServiceNow are in the global scope, however all custom applications created before application scope was implemented are also in the global scope.

Applications in the global scope are also not eligible for upload to the ServiceNow Store. ServiceNow recommends creating all new applications in a private application scope. If you who want existing custom applications to take advantage of application scope, you must move the application from the global scope.

Application Type and Scope

The provider and associated release version determine the application type:

  • Baseline applications: are applications provided by ServiceNow, Inc. with every release.
  • Custom applications from prior versions: are applications developed prior to application scoping (prior to Fuji).
  • New custom applications: are applications you built on the latest release version.

These applications types have the following scope values and application access settings:

Application Type Value in Application field Value in Scope field Application access settings
Baseline applications Global None Initially provided by ServiceNow, Inc. Can be configured.
Custom applications from prior versions Global None Initially provided by ServiceNow, Inc. Can be configured.
New custom applications The custom application name Automatically-generated namespace identifier Provided by during development.

For more information on setting application access permissions, see Application Access Settings.

Moving Changes between Application Scopes -- Manual Process

You may have need to move changes between global and private application scopes. For example:

  • You want an application created in a prior release to be a scoped application.
  • You want an application inadvertently made in the global scope to be in a private scope.
  • You want an application inadvertently made in a private scope to be in the global scope.
  • You want to move features from one private scope application to another private scope application.

In all cases, you must create a new application in the proper scope and manually move changes to the new application.

Note: When you move code changes to a private application scope, you must add the scope namespace qualifier to each function call. See Scripting in Scoped Applications.

Namespace Identifier

The system adds the namespace identifier to the front of all application tables, fields, and script names to uniquely identify the application artifacts. As the application developer, you cannot change or remove the identifier from application artifacts. This ensures that application artifacts are associated to the proper application and that all application artifacts have a unique name.

Namespace identifiers have this format:

x_[Vendor prefix]_[Application ID]_

The system computes the application namespace identifier from the following elements:

Element Requirements Sample Value
The prefix character for custom applications This string is always the x character. x
The separator character for namespace identifier prefixes This string is always the underscore character. The separator also appears between other elements in the prefix. _
The instance vendor prefix ( This string is two to five characters long. ServiceNow, Inc. generates this prefix for each customer. The instance stores the prefix in the system property. acme
The application ID This string can be up to 40 characters long. Typically the ID matches the application name with spaces replaced by underscores. book_rooms

The example values above generate a namespace identifier of x_acme_book_rooms.


The following examples illustrate generating namespace identifiers for applications, tables, and fields.

Action Element generated Explanation
1. Generate a namespace identifier for a private scope application called Book Rooms. x_acme_book_rooms This is a combination of the vendor prefix and application ID.
2. Generate a namespace identifier for a global scope application called Marketing Events. None The system does not generate namespace prefixes for global applications.
3. Add the conference rooms table to the Book Rooms application. x_acme_book_rooms_conference_rooms This table is in the Book Rooms scope so begins with the namespace identifier.
4. Add a Marketing Event table to a global application. u_marketing_event Custom tables in the global scope always use the u_ namespace identifier.
5. Select Book Rooms in the application picker and add the Capacity field on the Conference Rooms table. capacity The field is in the same scope as the table so it does not have its own namespace identifier. However, to dot-walk to the field in a script, you would use the full path including the table namespace identifier: x_acme_book_rooms_conference_rooms.capacity.
6. Select Book Rooms in the application picker and add the Theme field to the Marketing Event table. x_acme_book_rooms_theme The field is in a different scope from the table so it is prefixed with the x_acme_book_rooms namespace identifier. To dot-walk to the field in a script, you would use full path including the field namespace identifier: u_marketing_event.x_acme_book_rooms_theme.

Note: This example assumes that the Marketing Event table allows other application scopes to add fields. For more information, see Application Access Settings.

7. Select Marketing Events in the application picker and add the Theme field to the Marketing Event table. u_theme Custom fields in the global scope use the u_ prefix. To dot-walk to the field in a script, you would use u_marketing_event.u_theme.
Note: When you create a table or field, you cannot modify the namespace identifier but you can modify the rest of the name. For more information, see Creating Tables and Modifying Dictionary Entries.

Scripting Considerations

Scoped scripting allows you to customize your applications while limiting access and hiding the implementation details. For more information on scripting, see Scripting in Scoped Applications.

Table and Field Updates


The following tables support application scope.

Table Name New or Updated Description Extends
Package [sys_package] New Contains a record for each baseline application activated from a plugin. None
Application [sys_scope] New Contains a record for each application installed on the instance. Package [sys_package]
Store Applications [sys_store_app] New Contains a record for each application downloaded from the ServiceNow Store. Application [sys_scope]
Custom Application [sys_app] Updated Contains a record for each custom-authored application on the instance. Application [sys_scope]


The following fields have been added or updated to support application scope.

Field New or Updated Description
Application New [Read only] The application scope that contains the record. A value of global means the record belongs to the global application scope. Any other value means the record belongs to a private application scope.
Table Updated By default, lists of tables only show tables and database views that are in the same application scope as the current record. You can show or hide a the table for a custom application by setting its application access controls.