Architect track
Platform architecture & governance
Decisions that are cheap on day one and very expensive in year three.
5 sections · 33 entries
The customization ladder
Climb only as high as the requirement forces you. Every rung up adds upgrade and maintenance cost.
- 1 · AdoptUse the out-of-box process as designed. Change the process, not the platform.
- 2 · ConfigureProperties, forms, lists, choices, SLAs, notifications, assignment rules.
- 3 · No-codeFlow Designer, decision tables, UI policies, Workflow Studio, playbooks.
- 4 · Low-codeApp Engine Studio, UI Builder pages, catalog variables, declarative actions.
- 5 · Pro-codeScoped apps, Script Includes, scripted REST, custom components.
- ✕ · NeverEdit OOB scripts in place. Copy, extend or override so upgrades stay clean.
Scoped app or global?
Default to a scoped app for anything new. Global is the exception you justify.
| Situation | Choose | Why |
|---|---|---|
| New custom capability or product | Scoped app | Isolation, clear ownership, source control, Store-ready |
| Small tweak to an OOB ITSM process | Global (in an update set) | Lives where the OOB process lives |
| Reusable integration or utility layer | Scoped app | Versioned, deployable as one unit via the app repo |
| Needs APIs only global exposes | Global helper + scoped app | Keep the global surface tiny; call it through one Script Include |
| Several teams building in parallel | One scope per team or domain | Avoid update-set collisions and shared-file conflicts |
Instance & release pipeline
A predictable path from idea to production. Code moves up; data moves down (by clone).
- DevBuild in scoped apps linked to Git (source control) or named update sets.
- TestInstance Scan + ATF suites run automatically on every promotion.
- UAT / StageBusiness sign-off on prod-like data (masked). Upgrade rehearsals happen here.
- ProdDeploy through the Application Repository or a batched update set. No direct edits.
- Clone downRefresh sub-prods from prod on a schedule with exclusions, preservers and data masking.
Delivery & DevOps toolkit
What a mature ServiceNow delivery pipeline uses.
- Link a scoped app to a Git repo; branch per feature, commit from Studio / ServiceNow IDE
- Group child update sets under a parent so a release previews and commits as oneHidden gem
- Publish versioned scoped apps once; install the same version on every instance
- Automated code and config checks (and your own custom checks) before promotionHidden gem
- Regression suites for forms, catalog, server scripts and REST; run before every upgrade
- CI/CD API: trigger an ATF suite from Jenkins, GitHub Actions or Azure DevOpsHidden gem
- Remote instances you retrieve update sets from
- Custom scoped applications on the instance
Architecture review checklist
Ask these before a design goes to build.
- ✦OOB first. Which OOB capability did we evaluate, and why is it not enough?
- ✦Data model. Does this need a new table, or does an existing one (task, CMDB, CSDM) already model it? Custom tables can carry licence impact.
- ✦Ownership. Which scope, team and product owner own it in two years?
- ✦Volume. How many records per day, and what happens at 10× that?
- ✦Security. Which roles, ACLs and data classification apply? Any PII leaving the instance?
- ✦Failure. What happens when the integration, flow or MID Server is down?
- ✦Upgrades. Which OOB files does this touch, and how will skipped records be reviewed?
- ✦Testing. Which ATF tests prove it, and do they run in the pipeline?
- ✦Observability. How will we know it is broken before users tell us?
Nothing on this page matches. Try the search on the hub.
Snippets are provided as-is under the MIT licence, without warranty. Test in a sub-production instance first. ServiceNow is a trademark of ServiceNow, Inc.; this page is independent and not affiliated with or endorsed by ServiceNow.