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. Related ConceptsRuntime access to applications tables 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. 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.