Scoped Apps, App Files, and Requirements
Key Takeaways
- A scoped application has its own namespace prefix (for example x_acme_app) and an application boundary that controls access to its tables, scripts, and resources.
- The current application picker and the per-developer Application Scope sys property determine which scope owns every newly created artifact.
- Scoped apps default to protected cross-scope behavior: other scopes cannot read or write the app's tables unless Application Access and cross-scope privileges explicitly allow it.
- Application files are metadata records (tables, scripts, ACLs, flows) stored in sys_metadata; transactional records created by users or flows are data, not app files.
- CAD scenarios reward matching a requirement to the lowest-complexity declarative artifact before writing script or duplicating a data model.
Scoped Apps, App Files, and Requirements
A scoped application is a custom Now Platform app with its own namespace and application boundary. The platform generates a namespace prefix such as x_acme_inspect, and every table, field, script, and ACL the app creates is automatically prefixed and tagged to that scope. Scope does three jobs at once: it groups artifacts so the app packages cleanly, it makes ownership visible, and it protects the app from other scopes unless you deliberately open a door.
The global scope is the shared, unprefixed scope used by baseline platform configuration and legacy customization. Global has no application boundary, so its records are broadly accessible. For a new custom business application, global is usually the wrong default: it offers no namespace isolation, no clean packaging boundary, and no cross-scope protection.
| Concept | CAD-level meaning | Common exam trap |
|---|---|---|
| Scoped app | App with its own namespace and protected boundary | Assuming scope replaces the need for ACLs |
| Namespace | Auto-generated prefix (x_company_app) identity | Treating the prefix as a cosmetic label |
| Global scope | Shared, unprefixed legacy/baseline scope | Building every new app in global by habit |
| Application file | Metadata record in sys_metadata | Confusing app files with user transaction data |
| Application access | Controls cross-scope read/write/create/delete | Assuming another scope can always access tables |
| Current application picker | Sets the scope new artifacts are created in | Creating a table or script in the wrong app |
Cross-Scope Protection Defaults
By default, a scoped app's tables are set so that other applications cannot read or write them, and the app's script APIs are not callable from outside the scope. To let scope B query scope A's table, the developer of scope A must set Application Access (Can read / Can create / Can update / Can delete, and "Accessible from this/all application scopes"), and runtime cross-scope calls are governed by cross-scope privilege records the platform prompts you to approve. This default-deny posture is exactly why scoped apps are the answer when a scenario stresses isolation and controlled sharing.
What Counts as an Application File
An application file is a configuration or metadata artifact stored in the platform's metadata layer (sys_metadata). Examples include custom tables and dictionary entries, forms and views, application menus and modules, ACLs, business rules, client scripts, UI policies, script includes, flows, subflows, actions, notifications, system properties, and Automated Test Framework tests. These are the pieces you package, source-control, publish, install, upgrade, and troubleshoot.
Application files are not the same as operational data. A submitted request, an approval record, or a task a flow creates is transaction data living in the app's tables. The app defines and processes those records, but the records themselves are not the metadata that defines the application. This distinction is exactly what update sets and source control move (the metadata), not the data.
Turning Requirements Into App Design
Use requirements to pick the lowest-complexity platform capability, not to justify scripting by default:
- A field must become mandatory based on another field's value: start with a UI Policy, not a Client Script.
- A child record must point to one parent: use a reference field, never duplicated free text.
- A value differs across dev/test/prod: use a system property instead of hard-coding it.
- Users need one navigation area: build an application menu with focused modules.
- Another scope needs access: configure Application Access and approve cross-scope privileges deliberately.
Scope Review Checklist
- Is the current application picker set to the app you intend to modify before you create anything?
- Does the app have a clear namespace, application menu, and a coherent set of owned tables?
- Are UX files, security rules, and automation files all owned by the scoped app, not stranded in global?
- Are cross-scope reads, writes, creates, deletes, and script-call access intentionally configured?
When a CAD question describes a team that wants isolation from global changes, clear ownership, and controlled cross-scope behavior, the expected direction is a scoped application. The rest is lifecycle discipline: every artifact belongs where the app owner expects it to belong.
Reading the Namespace and Sys IDs
The namespace prefix is not decoration; it is how the platform routes ownership at runtime. A table named x_acme_inspect_finding tells you the company code (acme), the app (inspect), and the table (finding). Baseline tables have no x_ prefix (for example incident, task, cmdb_ci). On the exam, a table or script name that begins with x_ is a strong signal that the artifact is scoped, and an answer that says "any application can update it freely" is almost always wrong because of default cross-scope protection.
Worked Example: A Requirement Mapped to App Files
Suppose the requirement is: "Inspectors log facility findings; each finding belongs to one facility; a finding's Severity field must become mandatory when Status is set to Open; managers in test and prod should email a different distribution list." The clean scoped design maps each clause to the smallest artifact:
| Requirement clause | Correct app file | Wrong but tempting choice |
|---|---|---|
| Findings logged as records | Custom scoped table x_acme_inspect_finding | Extending Task when no workflow exists |
| Finding belongs to one facility | Reference field to facility table | Free-text facility name field |
| Severity mandatory when Status = Open | UI Policy with a condition | onChange Client Script setting mandatory |
| Different email list per environment | System property read by the flow | Hard-coded address inside a business rule |
Notice that none of these clauses required scripting. CAD scenarios consistently reward the declarative-first answer; script is the right choice only when configuration cannot express the logic cleanly, such as a multi-table calculation a UI Policy cannot reach.
Update Sets vs. Source Control vs. Data
A frequent confusion is what actually moves between instances. Update sets and Git source control capture application files (metadata) only, never the inspectors' finding records. Moving the data requires a separate mechanism such as import/export or a clone. If an exam stem says "we promoted the update set but the production list is empty," the issue is that data is not metadata, so the records never traveled, exactly the application-file-versus-transaction-data distinction above.
A developer creates a new module while the current application picker is set to the wrong scoped app. What is the most important consequence?