You've been managing deployments with CI/CD pipelines, Git branches, and Azure DevOps.

What This Question Really Tests

This question reveals whether you understand that ServiceNow's deployment model is fundamentally different from code-based deployments. Update Sets track configuration changes (not source code) and move them between instances — and the limitations catch every developer coming from a Git workflow.

The Mental Model

// Git Workflow (what you know)
// feature-branch → commit → pull request → merge → CI/CD → deploy
//
// ServiceNow Update Set Workflow
// Dev Instance → Make changes (auto-captured) →
//   → Complete Update Set → Export XML →
//   → Import to Test → Preview (conflict check) →
//   → Commit → Repeat to Prod

// An Update Set is like a Git stash that auto-captures every
// config change you make while it's "In Progress"

What Transfers and What Doesn't

• What works like Git: Changes are grouped logically (like a feature branch), they move from Dev → Test → Prod (like environments), and you can preview conflicts before committing (like merge conflict detection).
• What breaks your Git brain: There's no branching. No diffing individual lines. No rollback to a previous commit. No pull requests or code review workflow built-in. If two developers change the same Business Rule in separate Update Sets, the last one committed wins — there's no three-way merge.

Real-World Problems

• The 'wrong Update Set' disaster: A developer forgets to switch their active Update Set and makes changes in the wrong one. Now unrelated customizations are bundled together. In Git terms, it's like committing to main instead of your feature branch — except there's no git cherry-pick to fix it easily.
• Collision on shared records: Two developers modify the same UI Policy. Both Update Sets capture the full record. Whichever is committed second overwrites the first entirely — no merge, no conflict resolution. The mitigation: communicate, use batch Update Sets, or use ServiceNow's newer Source Control Integration (connects to Git for scoped apps).
• Data vs Configuration: Update Sets only capture configuration (scripts, UI policies, ACLs). They do NOT capture data (records in custom tables, user records, CMDB entries). Data migration requires separate strategies — Import Sets, scripts, or ATF data.

// Checking which Update Set you're working in (common sanity check)
var currentUS = gs.getUpdateSetName();
gs.info('Currently working in: ' + currentUS);

// Programmatically moving a record to the correct Update Set
var us = new GlideRecord('sys_update_set');
us.addQuery('name', 'My Feature Update Set');
us.addQuery('state', 'in progress');
us.query();
if (us.next()) {
  // Now switch context
  gs.setCurrentUpdate(us.sys_id);
}