Application Scope Security

Application Scope Security in ServiceNow

Application Scope Security is a fundamental concept in ServiceNow that governs how applications interact with each other and protect their data, logic, and resources from unauthorized access. Understanding this concept is critical for the ServiceNow Certified Application Developer (CAD) exam.

Why Is Application Scope Security Important?

In a ServiceNow instance, multiple applications coexist — some built by ServiceNow, some by third-party vendors, and some custom-built by your organization. Without proper boundaries, one application could inadvertently (or intentionally) modify another application's tables, scripts, or configurations. Application Scope Security addresses this by:

- Protecting intellectual property: Developers who build applications can ensure their code and configurations are not tampered with by other applications.
- Maintaining data integrity: Preventing unauthorized applications from reading, writing, or deleting records in tables they do not own.
- Ensuring stability: Reducing the risk that changes in one application will break the functionality of another.
- Supporting governance: Providing administrators with a structured way to control cross-application interactions.

What Is Application Scope Security?

Every application in ServiceNow is developed within a specific application scope. The scope acts as a namespace and a security boundary for all artifacts (tables, scripts, UI elements, etc.) that belong to that application. There are two primary types of scopes:

1. Global Scope: The default scope in ServiceNow. Artifacts in the global scope can generally access resources across the instance without restriction. Legacy and many out-of-box applications run in the global scope.

2. Private (Scoped) Application Scope: Custom or store applications are typically built within a private scope (e.g., x_mycompany_myapp). Scoped applications have restricted access to resources outside their own scope unless explicitly granted permission.

How Does Application Scope Security Work?

Application Scope Security operates through several mechanisms:

1. Application Access Settings
Every scoped application has configurable Application Access settings that determine what other applications can do with its resources. These settings are found on the application record and include:

- Can read: Allows other scoped applications to read records from this application's tables.
- Can create: Allows other scoped applications to create records in this application's tables.
- Can update: Allows other scoped applications to update records in this application's tables.
- Can delete: Allows other scoped applications to delete records from this application's tables.
- Caller access: Controls whether other applications can call script includes, REST APIs, or other scripted resources belonging to this application.
- Allow access to this table via web services: Controls web service access to tables.
- Accessible from: Determines whether access is granted to All application scopes or only to specific scopes.

These settings can be configured at both the application level and the individual table level. Table-level settings override application-level defaults.

2. Cross-Scope Access Requests
When a scoped application tries to access a resource outside its scope, ServiceNow generates a cross-scope access request. A system administrator must approve or deny this request. Once approved, the requesting application can interact with the target resource according to the permissions granted. These requests are tracked in the sys_scope_privilege table.

3. Runtime Access Control
At runtime, the platform enforces scope security. If a scoped application's server-side script attempts to access a table or script include from another scope without proper authorization, the platform will block the operation and log a security violation. This enforcement happens automatically and does not require developer intervention.

4. Scripting in Scoped Applications
Scoped applications have access to a restricted set of APIs compared to global-scope scripts. For example:

- Scoped scripts use gs.info(), gs.warn(), and gs.error() instead of gs.log().
- Certain GlideRecord operations are restricted unless cross-scope privileges are granted.
- The current object in business rules behaves consistently, but direct table access outside the scope requires permissions.
- Some global APIs like GlideHTTPRequest are not available in scoped applications; scoped equivalents like sn_ws.RESTMessageV2 are used instead.

5. Protecting Script Includes
When creating a Script Include in a scoped application, you can mark it as Accessible from: This application scope only or All application scopes. If set to This application scope only, no other application can call or reference that Script Include without a cross-scope privilege being granted.

6. Application Scope and Update Sets
When working in a scoped application, all changes made are captured in the update set associated with that scope. This ensures that artifacts remain properly associated with their application and do not leak into other scopes or update sets.

Key Concepts to Remember

- The Global scope is the least restrictive; it can access most resources but should be used carefully.
- Scoped applications are sandboxed by default and must be explicitly granted access to external resources.
- Application Access settings are the primary mechanism for controlling what other scopes can do with your application's tables and resources.
- Cross-scope privileges (sys_scope_privilege) record approved interactions between scopes.
- Table-level access settings override application-level access settings.
- Scoped applications use a restricted API set compared to global scope.

Practical Example

Suppose you create a scoped application called x_acme_hr_app with an HR Cases table. By default, other scoped applications cannot read, create, update, or delete records in the HR Cases table. If another application, x_acme_finance_app, needs to read HR Cases, the following must happen:

1. The HR App's Application Access settings must allow read access from other scopes, OR
2. A cross-scope access request must be generated and approved by an admin when the finance app attempts to read HR Cases records.


Exam Tips: Answering Questions on Application Scope Security

1. Understand the default behavior: By default, scoped applications cannot access resources in other scopes. Questions often test whether you know that access is denied by default and must be explicitly granted.

2. Know the difference between Global and Scoped: Expect questions that ask you to distinguish between the capabilities and restrictions of global vs. scoped applications. Remember that global scope has broader access but scoped applications are more secure.

3. Application Access settings are key: Many exam questions focus on the specific access flags — Can read, Can create, Can update, Can delete, and Caller access. Know where these are configured (on the application record and on individual table records) and understand that table-level settings take precedence.

4. Cross-scope privileges: Be prepared for questions about what happens when a scoped app tries to access another scope's resource. Know that a cross-scope access request is generated and must be approved by an administrator.

5. API restrictions: The exam may test your knowledge of which APIs are available in scoped applications vs. global scope. Remember that scoped apps use gs.info() instead of gs.log(), and that web service calls use scoped APIs like sn_ws.RESTMessageV2.

6. Watch for tricky wording: Questions may present scenarios where an application "cannot access" a table. Before choosing an answer about ACLs or roles, consider whether the issue is actually a scope security restriction rather than a user-level security issue.

7. Remember the sys_scope_privilege table: If a question asks where cross-scope access approvals are stored, the answer is the sys_scope_privilege table.

8. Script Include accessibility: Know that Script Includes in scoped apps have an "Accessible from" field. If set to "This application scope only," other apps cannot use it without explicit privileges.

9. Scenario-based questions: The CAD exam frequently uses scenarios. When a question describes a scoped application that cannot interact with another application's data, your first thought should be about Application Access settings and cross-scope privileges — not about ACLs or user roles.

10. Practice in a PDI: The best way to solidify your understanding is to create two scoped applications in a Personal Developer Instance (PDI), attempt to access one application's table from the other, and observe the cross-scope access request workflow in action.

By mastering Application Scope Security, you will be well-prepared to answer related exam questions confidently and to build secure, well-architected applications on the ServiceNow platform.