Scoped App, Global Fields, and a Release Freeze
Your team is building a custom invoice-approval application in a scoped app for three finance departments, processing about 4,500 invoices a month with approval chains up to three levels. The request also includes two new fields on the global Incident table, and the scoped app must call an existing global Script Include owned by the ITSM team. A developer proposes creating the Incident fields from inside the scoped app and copying the global Script Include into the new scope so everything stays together. Deployment moves from dev to test to prod using update sets, and there is a hard freeze on the global scope during the release window.
1. Where should the two Incident fields be created, and how should the scoped app read them? Explain the trade-off.
Read the worked answer
Recommendation: create the fields in the global scope, not inside the scoped app.
- The Incident table is global. A scoped app can only touch it with cross-scope privileges, and any dictionary record it creates becomes a cross-scope artifact owned by the wrong scope. That inverts the dependency: a global table now upgrades with a scoped app attached to it, and the global freeze makes it worse.
- Have a global admin add the two fields in a global update set, then explicitly grant the scoped app access (cross-scope access record or the field-level accessible-from setting) rather than copying data into the scoped app.
- Trade-off: cross-scope access widens the coupling and needs review each release, but duplicating the value into a scoped table creates two sources of truth and sync bugs. Coupling you can see beats duplication you cannot.
2. The global Script Include: copy it, call it directly, or wrap it? Recommend and justify.
Read the worked answer
Do not copy. A copied Script Include is a fork: the ITSM team fixes a bug, your copy keeps the bug, and nobody notices until an approval routes wrong.
Two viable options:
- Call it directly. Set its Accessible from to All application scopes (or add a cross-scope privilege). Cleanest if the API is stable and narrow.
- Global wrapper. Keep the original scoped to global, and expose only the two or three methods you need through a thin global Script Include marked accessible to all scopes.
Judgement: if the include exposes a broad, unstable API, the wrapper wins because it limits what your app can break and what a future refactor breaks. If the API is small and stable, direct access is less moving parts. Either way, document the contract and add a test that fails if the method signature changes.
3. Design the update set path from dev to test to prod given the global freeze.
Read the worked answer
Two update sets, sequenced:
GLOBAL-<release>-IncidentFields- the dictionary records, owned by global, created before the freeze window or by an exception.SCOPED-<release>-InvoiceApproval- the scoped app artifacts, including the access grant that references the fields.
Order matters: the global set must be retrieved and committed first in every instance, or the scoped app deploys against fields that do not exist and the access record fails to resolve.
Practical points:
- Retrieve and preview in test, commit, then run the approval smoke test before touching prod.
- Scoped app update sets carry their scope and cannot be moved to another scope; never mix global and scoped records in one set.
- Keep a back-out set (or a recorded rollback script) for the global fields, since the freeze means you cannot quickly re-deploy a fix.
- If the freeze blocks the global set, ship the scoped app behind a feature flag that defaults off until the fields land.