Scoped applications
Build in a scope: namespaces, cross scope access, restrictions and how scoped apps move between instances.
Build in a scope: namespaces, cross scope access, restrictions and how scoped apps move between instances.
- Scope is a boundary for tables, code and records
- Cross scope privileges are explicit and auditable
- gs.log is replaced by gs.info, gs.warn and gs.error
- Scoped apps version and publish rather than travelling in update sets
Why scope exists
A scoped application owns its tables, scripts and records under a namespace such as x_acme_orders. Nothing outside the scope can read or write those artefacts unless the app publishes access, which prevents one team breaking another team work.
Cross scope access
When your code touches a table in another scope, the platform creates a cross scope privilege record that an admin approves. Global scope is not automatically open either, so plan the read and write permissions your app needs before go live rather than firefighting them.
What changes in scoped code
Several global conveniences are restricted.
- gs.log is unavailable, use gs.info, gs.warn and gs.error
- Direct access to some system tables requires an explicit privilege
- GlideRecord queries honour ACLs by default when run in scoped scripts
- Scripts run with the scope permissions, not the caller role set
Delivery
Scoped apps move as application files through the ServiceNow Store, a repository link, or a versioned application publish. That is cleaner than update sets and is one of the strongest reasons to build in scope.