ServiceNow's update set switching mechanism requires the sys_id of the target update set, not its name or display value. The platform maintains update set context in the user session, but GlideUpdateSet.setCurrent() bypasses normal UI validation completely. Most developers assume they can pass an update set name directly, leading to silent failures where the switch appears to work but subsequent changes aren't captured. The critical mistake is running this in production where update sets should never be manipulated programmatically.
When to use this
- Automating development workflows where you need to switch context before making configuration changes
- Scheduled jobs in dev environments that need to isolate their changes to specific update sets
- Data migration scripts that need to prevent accidental configuration capture
- Cleanup scripts that need to work in the Default update set to avoid creating spurious update records
When NOT to use this
- Never in production environments - use proper release management instead
- Don't use in Business Rules or Script Includes that execute during normal user operations - this changes global state unpredictably
- Don't use to temporarily switch update sets within a single script execution - the change persists beyond your script
- Don't use when you only need to query update set information - use direct GlideRecord queries on
sys_update_setinstead
Key behaviors and gotchas
- Only update sets with
state= 'in progress' can be set as current - completed or ignored update sets will be silently rejected - The change affects only the current user session - other users' active update sets remain unchanged
- Domain separation applies - you can only switch to update sets visible in your current domain context
- Passing an invalid
sys_idfails silently - the current update set remains unchanged with no error message - Scoped applications cannot switch to global update sets, and global scope cannot switch to scoped update sets
- Changes made after switching will be captured in the new update set immediately - there's no "pending" state
This method bypasses all UI safety checks and can leave your instance in an inconsistent state. Always verify you're in a development environment before executing, and never run this in automated processes that might execute in production.
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.