Application Scope

Application Scope in ServiceNow – Complete Guide for CAD Exam

Understanding Application Scope in ServiceNow

Application Scope is one of the most fundamental concepts in ServiceNow application development. Whether you are building a new custom application or working with existing ones, understanding how scoping works is essential for the Certified Application Developer (CAD) exam and for real-world development.

Why Is Application Scope Important?

Application Scope exists to protect applications from being modified or interfered with by other applications. Without scoping, any script, table, or configuration in one application could potentially conflict with or overwrite resources in another application. Here is why it matters:

• Data Protection: Scope prevents unauthorized access to an application's data, tables, and records from other applications.
• Code Isolation: Scripts and business logic within one scope cannot accidentally interfere with scripts in another scope.
• Namespace Management: Each scoped application gets a unique namespace (prefix), preventing naming conflicts between applications. For example, a table in a scoped app might be named x_myco_myapp_task rather than just task.
• Controlled Sharing: Application scope allows developers to explicitly define what resources (tables, scripts, properties) are accessible to other applications through Application Access settings.
• Update Management: Scoped applications can be independently versioned, published, and updated through the ServiceNow App Store or Update Sets without impacting other applications.

What Is Application Scope?

Application Scope is a logical boundary that encapsulates all artifacts (tables, scripts, UI elements, business rules, etc.) belonging to a specific application. Every application in ServiceNow operates within a scope.

There are two primary types of scope:

1. Global Scope: The default scope in ServiceNow. All out-of-the-box (OOTB) ServiceNow applications and many legacy customizations reside in the global scope. Resources in the global scope are generally accessible to all other applications unless explicitly restricted. The global scope does not have a vendor prefix.

2. Private/Scoped Application Scope: Custom applications created by developers or obtained from the ServiceNow Store operate within their own private scope. These applications have a unique namespace prefix (e.g., x_mycompany_appname). Access to their resources is restricted by default and must be explicitly granted.

Key Components of Application Scope

• Scope Name: A unique identifier for the application (e.g., x_myco_hr_app).
• Application Record: The sys_app or sys_store_app record that defines the application and its scope.
• Application Access Settings: Configuration that determines whether other scoped applications or the global scope can access the application's resources.
• Application Picker: The scope selector in the ServiceNow banner/header that allows developers to switch between application scopes during development.

How Does Application Scope Work?

When you create a new application in ServiceNow using Studio or the Application Creator, the platform automatically assigns a scope to that application. Here is how scoping functions in practice:

1. Namespace Prefixing
All artifacts created within a scoped application automatically receive the application's namespace prefix. For example:
• A table created in scope x_myco_hr might be named x_myco_hr_employee.
• A script include in that scope would be prefixed accordingly.
This prevents naming collisions with tables or scripts in other applications.

2. Runtime Access Control
At runtime, ServiceNow enforces scope boundaries. When a script in Application A tries to access a table or resource owned by Application B, the platform checks the Application Access settings of Application B to determine whether access is permitted. The four key access controls are:

• Can read: Can other applications read records from this application's tables?
• Can create: Can other applications create records in this application's tables?
• Can update: Can other applications update records in this application's tables?
• Can delete: Can other applications delete records from this application's tables?

Additionally, there is a setting for whether the application allows access to its script includes from other scopes, and whether cross-scope access is permitted for configuration records.

3. Cross-Scope Privileges
If a scoped application needs to interact with resources in another scope (or in the global scope), a cross-scope privilege record may be required. This is essentially a permission record that explicitly grants one application the right to access specific resources in another application. These are stored in the sys_scope_privilege table.

4. The Global Scope Exception
The global scope has broader access by default. Scripts running in the global scope can generally access resources in scoped applications (subject to Application Access settings). However, scoped applications have more restricted access to global resources and to each other's resources.

5. APIs and Scope
ServiceNow provides different API classes depending on scope:
• Scoped APIs: A subset of APIs available to scoped applications (e.g., GlideRecord, GlideSystem, GlideScopedEvaluator). Not all global APIs are available in scoped applications.
• Global APIs: The full set of APIs available in the global scope. Some APIs like GlideRecord.setWorkflow() are not available in scoped applications for security reasons.

Developers working in scoped applications must use the Scoped API documentation to ensure they are using supported methods.

6. Application Files and the Current Scope
When you create or modify a record (like a Business Rule, Script Include, or UI Policy), it is automatically associated with whatever scope you currently have selected in the Application Picker. This is critical — if you accidentally have the wrong scope selected, your artifact will be created in the wrong application.

How to Configure Application Access

To configure what other applications can do with your scoped application's resources:

1. Navigate to System Applications > Studio or open the application record.
2. Open the application record (sys_app).
3. Scroll down to the Application Access related list or section.
4. Set the permissions for Accessible from (All application scopes / This application scope only).
5. Configure Can read, Can create, Can update, Can delete checkboxes as needed.
6. Configure whether callers can access script includes from other scopes.

Best Practices for Application Scope

• Always develop custom applications in a scoped application rather than in the global scope, unless there is a compelling reason to use global.
• Use Studio for scoped application development as it automatically manages scope context.
• Be intentional about Application Access settings — only expose what is necessary.
• Test cross-scope interactions thoroughly, as scope restrictions can cause unexpected errors at runtime.
• Use scoped script includes to expose functionality to other applications in a controlled manner by marking them as Accessible from: All application scopes.
• Remember that GlideRecord operations in scoped apps are subject to the target table's Application Access settings.

Common Scenarios in the CAD Exam

The CAD exam frequently tests your understanding of Application Scope through scenario-based questions. Here are common scenarios:

• A developer creates a Business Rule but it does not fire — possible cause: the developer was in the wrong application scope when creating the Business Rule.
• A scoped application cannot read records from another application's table — possible cause: the target application's access settings do not allow read access from other scopes.
• A developer needs to call a Script Include from another scope — the Script Include must be set to accessible from all application scopes, and a cross-scope privilege may be needed.
• Questions about what happens when you switch scopes using the Application Picker.
• Questions about table naming conventions and namespace prefixes for scoped applications.

Exam Tips: Answering Questions on Application Scope

1. Know the difference between Global and Scoped: The exam will test whether you understand that global scope has broader access and that scoped applications are restricted by default. Remember: scoped applications protect their resources, and access must be explicitly granted.

2. Understand the Application Picker: Many exam questions involve scenarios where a developer is working in the wrong scope. Always consider whether the current scope selection could be causing the issue described in the question.

3. Memorize Application Access settings: Know the four CRUD permissions (Can read, Can create, Can update, Can delete) and the Accessible from setting (All application scopes vs. This application scope only). These are frequently tested.

4. Cross-Scope Privileges: Understand that when one scoped application needs to access another scoped application's resources, cross-scope privilege records (sys_scope_privilege) may be required. The exam may ask about how to grant or troubleshoot cross-scope access.

5. API Availability: Remember that scoped applications have access to a subset of the full ServiceNow API. If a question mentions an API method that doesn't work in a scoped app, consider whether the method is only available in the global scope.

6. Namespace Prefixes: Scoped application artifacts use the format x_[vendor prefix]_[app name]_[artifact name]. The exam may test your ability to identify which scope an artifact belongs to based on its name.

7. Default Behavior: By default, a new scoped application's resources are not accessible from other scopes. This is the most secure default. The developer must explicitly open access. If an exam question describes a newly created scoped app whose resources cannot be accessed from another app, the answer is likely related to the default restrictive access settings.

8. Script Includes Across Scopes: To make a Script Include callable from other scopes, it must be explicitly marked as accessible from all application scopes. The exam often tests this with scenarios where a Script Include returns an error when called from a different scope.

9. Elimination Strategy: When facing a scope-related question, eliminate answers that suggest modifying global system properties or ACLs if the scenario is clearly about application-to-application access. Application Access settings and cross-scope privileges are the correct mechanisms for controlling inter-application access.

10. Studio vs. Global Context: Remember that Studio automatically sets the correct application scope for development. If a question mentions a developer working outside of Studio (e.g., directly in the platform UI), scope misalignment is a common pitfall to watch for.

Summary

Application Scope is ServiceNow's mechanism for isolating and protecting applications from each other. It provides namespace management, runtime access control, and controlled sharing of resources between applications. For the CAD exam, focus on understanding the difference between global and scoped applications, how Application Access settings work, how cross-scope privileges function, and common troubleshooting scenarios involving scope misalignment. Always check the current application scope context when debugging issues, and remember that scoped applications are restrictive by default.