Application scoping protects applications by identifying and restricting access to
application files and data.
Administrators can specify what parts of an application are accessible to other applications
from:
The Custom application record
Each application Table record
For example, suppose that 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 can't unless you give them 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.
By default, all custom applications have a private scope that uniquely identifies them and
their associated artifacts with a namespace identifier. The application scope prevents naming
conflicts and allows the contextual development environment to determine what changes, if any,
are permitted. Application developers specify an application scope when they create an
application.
Tip: Global apps can alter data that you don't intend to alter. You should leverage
scoped apps to create new tables, and consider transitioning old ones to scoped apps. This allows
you to split responsibilities with Delegated Development.
Global scope
The global scope is a special application scope that identifies applications developed
prior to application scoping, or applications intended to be accessible to all other global
applications.
Applications in the global scope do not append a unique namespace identifier to the application
name. Global applications can have naming conflicts and data collisions when developers create
multiple global applications with the same name.
Since all global applications are in the same scope, they bypass scope protections. Global
applications allow other global applications access to their tables to
Read records
Run API requests
Create configuration records
Typically, only applications provided by ServiceNow are in the global scope, however
any custom applications created before application scope was implemented are also in the global
scope.
Applications in the global scope are eligible for upload to the application repository, but not
to the ServiceNow Store .
Namespace identifier
The system adds a namespace identifier to the front of application artifacts such as
tables, scripts, and configuration records.
The identifier cannot be changed or removed from application artifacts to ensure that they are
always associated to the proper application and that they have a unique name.
The system generates a namespace identifier from the following information:
Table 1. Elements used to generate a namespace identifier
Element
Requirements
Sample Value
The prefix characters for a scoped application.
Scoped applications always start with an x_ prefix.
x_
The instance customer prefix (glide.appcreator.company.code)
This string is two to five characters long. ServiceNow generates this prefix for
each customer. The instance stores the prefix in the
glide.appcreator.company.code system property.
acme
The application ID
This string can be up to 40 characters long. Application developers set this ID when
they create the application. The system uses the application name by default.
book_rooms
The example values generate a namespace identifier of x_acme_book_rooms.
Namespace identifier examples
The following examples illustrate generating namespace identifiers for applications,
tables, and fields.
Table 2. Example namespace identifiers
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 .
