Scoped Apps, App Files, and Requirements
Key Takeaways
- A scoped application owns its artifacts inside an application boundary and namespace, while global is the shared legacy scope.
- The current application picker matters because newly created tables, modules, scripts, ACLs, and flows belong to the selected scope.
- Application files are metadata artifacts that define the app; they are different from day-to-day transactional records users create.
- CAD scenarios often reward matching requirements to existing platform capabilities before scripting or duplicating data models.
- Application access and cross-scope privileges govern how other scopes interact with a scoped app's tables and resources.
Scoped Apps, App Files, and Requirements
A scoped application is a custom ServiceNow application with its own application boundary and namespace. The scope keeps the app's artifacts grouped, makes ownership visible, and gives the platform a way to control how the app interacts with other scopes. The global scope is the shared platform scope, often used by older or broad platform configuration, but it is usually not the right default for a new custom business application.
The CAD exam tests scope as a practical development control. Before creating a table, form, module, business rule, flow, script include, or ACL, check the current application picker. If the wrong application is selected, the artifact can land in the wrong scope. That creates packaging, security, source control, and maintenance problems later because the app is no longer a clean set of related files.
| Concept | CAD-level meaning | Common exam trap |
|---|---|---|
| Scoped app | App with its own namespace and controlled boundary | Assuming scope removes ACL requirements |
| Namespace | Prefix and identity that separate app artifacts | Treating the prefix as just a label |
| Global scope | Shared platform scope | Building every custom app globally by habit |
| Application file | Metadata record that defines the app | Confusing app files with user transaction data |
| Application access | Cross-scope table and resource permissions | Assuming another scope can always read or write |
| Current application picker | Controls where new artifacts are created | Creating a table or script in the wrong app |
What Counts as an Application File
An application file is a configuration or metadata artifact that belongs to the app. Examples include custom tables, dictionary entries, forms, views, application menus, modules, ACLs, business rules, client scripts, UI policies, script includes, flows, subflows, actions, notifications, properties, and test records. These are the pieces you package, source-control, publish, install, upgrade, or troubleshoot.
Application files are not the same as operational records. A request submitted by a user, an approval record, or a task created by a flow is transaction data. The app may create or process those records, but they are not normally the metadata that defines the application itself.
Turning Requirements Into App Design
Use requirements to select platform capabilities, not to justify custom build by default.
- If a form field must become mandatory based on another value, start with a UI Policy.
- If users need a single navigation area, create an application menu with focused modules.
- If a child record should point to one parent, use a reference field instead of duplicated text.
- If a value differs between dev, test, and prod, use an application property instead of hard-coding it.
- If another scope needs access, configure application access and approve cross-scope privileges deliberately.
The design pattern is simple: choose the lowest-complexity platform artifact that satisfies the requirement and keeps ownership inside the correct scope. Custom script is valid when configuration cannot express the logic cleanly, but CAD scenarios usually penalize scripts that replace declarative tools without a reason.
Scope Review Checklist
- Is the current application picker set to the app you intend to modify?
- Does the app have a clear namespace and application menu?
- Are tables, UX files, security rules, and automation files owned by the scoped app?
- Are cross-scope reads, writes, creates, deletes, and web service access intentionally configured?
- Can the app be moved, versioned, and reviewed as a coherent package?
When a CAD question says a team wants isolation from global changes, clear ownership, and controlled cross-scope behavior, the expected design direction is a scoped application. The details then become lifecycle discipline: every artifact should belong where the app owner expects it to belong.
A developer creates a new module while the current application picker is set to the wrong scoped app. What is the most important consequence?