🚀 ServiceNow — Deployment & Environment Management
ServiceNow Developer Guide · Digital Kimya
Moving configuration from your development sandbox to a live production instance
Diagramme interactif — Pipeline DEV → TEST → PROD
--- is one of the most failure-prone steps in a ServiceNow project. The Update Set mechanism is powerful but unforgiving — a missed dependency, an unresolved conflict, or a forgotten table entry can bring a deployment to a halt. This guide covers every step of the DEV → TEST → PROD pipeline with the detail needed to deploy confidently.
The Three-Instance Model
DEV Instance TEST Instance PROD Instance
(Personal Dev) ──► (Recette / UAT) ──► (Live)
Update Set Update Set| Instance | Purpose | Who uses it |
|---|---|---|
| DEV (PDI) | Build and unit-test configurations | Developers |
| TEST | Integration testing, UAT, regression | QA, business users, UAT team |
| PROD | Live environment — real users, real data | Everyone |
The golden rule: no configuration changes are made directly in PROD. Everything goes DEV → TEST → PROD via Update Sets, with sign-off at each stage.
Update Set — The Transport Mechanism
An Update Set (sys_update_set) is a container that records every configuration change you make while it is set as "Current". Think of it as a transaction log for your customisations.
The Update Set Lifecycle
Update Set — DEV to PROD Pipeline
Click any step to expand · 7 steps
What IS and IS NOT Captured
This is the most tested concept in the CSA exam and the most common production incident cause.
✅ What IS Captured in an Update Set
These are configuration objects — the structure and logic of the platform:
| Category | Examples |
|---|---|
| Scripts | Business Rules, Client Scripts, Script Includes, Scheduled Jobs |
| UI | UI Policies, UI Actions, UI Macros, UI Pages, Form Layouts, Views |
| Workflow | Flow Designer flows, Classic Workflows, Approval definitions |
| Security | ACL rules, Roles |
| Data structure | Dictionary entries (new fields), Choice Lists, Table definitions |
| Notifications | Email notifications, Templates |
| Service Catalogue | Catalogue items, Variables, Workflows |
❌ What is NOT Captured
These are data records — the content, not the structure:
| What | Why not captured | How to migrate if needed |
|---|---|---|
| Incident / Problem / Change records | Runtime data, not configuration | Import Set or clone |
| User records (sys_user) | Data, not configuration | Import Set from CSV/LDAP |
| Attachments | Binary data | Manual or scripted API transfer |
| Scheduled job execution history | Logs | Not migrated — starts fresh |
| Import Set rows | Transient data | Re-run import on target |
| User preferences | Personal settings | Not migrated |
| Application logs | sys_log entries | Not migrated |
The mental model: configurations yes, data no.
⚠️ Classic trap: you create a test Incident in DEV to verify your Business Rule. That incident will NOT appear in TEST. Only the Business Rule itself travels via Update Set. You must recreate test data in each environment.
Preview — Conflict Detection in Detail
Before committing an Update Set, the Preview step is mandatory. It scans the target instance and flags three types of issues:
Preview Status Codes
| Status | Meaning | Action required |
|---|---|---|
| ✅ Accepted | No conflict, ready to commit | None |
| ⚠️ Conflict | Same record exists with different content | Resolve: accept remote or skip |
| ❌ Error | Missing dependency (e.g., a field that doesn't exist on target) | Fix dependency first |
Conflict Resolution
Scenario: You modified Business Rule "Set Priority" in DEV. The same rule was also modified in TEST by another developer.
Preview shows: Conflict on sys_script — Set Priority
Options:
- Accept Remote → Your DEV version will overwrite TEST's version after commit
- Skip → TEST's version is preserved, your changes are ignored for this record
Best practice:
- Always communicate with the team before making overlapping changes
- Document which version was accepted and why
- If in doubt, merge the changes manually before creating the Update Set
Instance Clone
A clone is a complete copy of one instance's data and configuration into another. Typically used to refresh TEST with PROD data so UAT reflects real-world content.
PROD ──full copy──► TEST (overwrites everything in TEST)What Clone Copies
- All records (incidents, users, configuration items, catalogue)
- All configurations (scripts, workflows, ACLs)
- All attachments
- All scheduled job definitions (not their history)
⚠️ What Clone Destroys
Everything in the target instance is overwritten. This includes:
- Any DEV/TEST-specific configurations not yet in PROD
- Integration credentials configured for TEST endpoints
- Any Update Sets that were in TEST but not promoted to PROD
Clone Excludes
To protect TEST-specific settings during a clone, configure Clone Excludes (System Clone → Exclude Tables):
| What to exclude | Why |
|---|---|
| Integration credentials (REST endpoints) | PROD creds should not overwrite TEST creds |
| Email configuration | Avoid TEST sending real emails after clone |
| Active Update Sets | Preserve in-progress DEV work in TEST |
| User passwords (in some configs) | Security isolation |
App Manager — Scoped Application Deployment
For scoped applications, ServiceNow provides the Application Manager as an alternative to Update Sets:
| Feature | Update Set | App Manager |
|---|---|---|
| What it carries | Any configuration changes | Scoped App only |
| Transport mechanism | XML file | App Repository (internal) / ServiceNow Store |
| Version control | Manual (file naming) | Built-in versioning |
| Dependency management | Manual | Automatic (manifest) |
| Best for | Ad-hoc changes, cross-table customisations | Packaged apps, plugins |
Workflow for Scoped App deployment:
Studio → Publish → App Repo → Install on target instanceMerge — Combining Update Sets
When multiple Update Sets need to be deployed together, use Merge:
- Select the Update Sets to merge (they must be in Complete status)
- ServiceNow creates a new merged Update Set
- Conflicts within the merged set are flagged for resolution
- The merged set is deployed as a single unit
When to use merge:
- Multiple developers worked in parallel on related features
- A bug fix and a feature fix are ready at the same time
- You need a single deployment artefact for a change window
CSA / CIS Exam Quick Reference
| Question topic | Answer |
|---|---|
| What records travel in an Update Set? | Configuration only — not data (incidents, users, attachments) |
| What happens if no ACL matches? | Access denied (deny by default) |
| Direct role assignment on user is... | Anti-pattern — use group-based roles |
| Preview before commit does what? | Detects conflicts between Update Set and target instance |
| Instance Clone direction for refreshing TEST | PROD → TEST (overwrites TEST) |
| Accept Remote in Preview means... | Your Update Set version overwrites the existing version |
| Scoped app vs Global for new development | Always scoped app — isolation, upgrade safety, portability |
Deployment Checklist
Before starting development:
☐ Update Set created with descriptive name and ticket reference
☐ Update Set set as "Current" in DEV
☐ DEV is on the same release as TEST and PROD
During development:
☐ All changes made in DEV only
☐ No direct modifications in TEST or PROD
☐ Tested with impersonation as non-admin users
Ready to promote to TEST:
☐ Update Set status set to "Complete"
☐ XML exported and saved in project documentation
☐ Change request raised and approved
☐ TEST maintenance window confirmed
In TEST:
☐ Update Set imported from XML
☐ Preview run — all conflicts resolved and documented
☐ Committed to TEST
☐ UAT completed with sign-off from business users
Ready for PROD:
☐ Same XML imported to PROD
☐ Preview run in PROD — conflicts resolved
☐ Production maintenance window scheduled
☐ Rollback plan documented (which records to manually revert if needed)
☐ Committed to PROD during maintenance window
☐ Post-deployment smoke test completed
☐ Change record closedPart of the Digital Kimya (opens in a new tab) ServiceNow Guide Series — Identity & Access · Scripts & Logic · Tables & Data