Application scope 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 not other applications 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. 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 application, 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 also not eligible for upload to the application repository or 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 vendor 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.