ServiceNow Update Sets: The Complete Developer Guide

Update Sets are the primary mechanism for moving configuration changes between ServiceNow instances. They are simple in concept but full of edge cases that cause production incidents for developers who don't know the details.

What Gets Captured in an Update Set

Update Sets capture configuration records — not data. The key distinction:

Captured (configuration):

• Business Rules, Client Scripts, Script Includes
• Flow Designer flows, actions, subflows
• UI Policies, UI Actions
• Form layouts and views
• ACLs and roles
• Catalog items and variables
• Scheduled jobs
• Application menus and modules

NOT captured (data):

• Incident, Problem, Change records
• User records and group memberships
• Assignment rules
• Notification records (can be captured but need to be in scope)
• System properties (need manual transfer or separate Update Set)

Update Set Workflow

Development Instance
    → Create Update Set
    → Make changes (all changes captured automatically)
    → Complete Update Set
    → Export to XML

Test Instance
    → Import XML
    → Preview Update Set (check for issues)
    → Commit Update Set
    → Test

Production Instance
    → Import XML
    → Preview Update Set
    → Commit Update Set

The Preview Step — Never Skip It

Previewing an Update Set before committing checks for:

• Conflicts — same record modified in both instances
• Missing records — the Update Set references records that don't exist in the target
• Circular references — Update Sets that depend on each other

Skipping preview and committing directly is the single most common cause of Update Set-related production incidents.

Handling Conflicts

When a conflict is detected, you have three options:

1. Accept Remote — use the version from the Update Set (overwrites target)
2. Accept Local — keep the target version (ignores the Update Set change)
3. Merge — manually review and combine both versions

For script conflicts, always choose Merge and carefully review both versions. Automatically accepting remote can silently overwrite production fixes that were applied directly.

Merging Multiple Update Sets

When multiple developers are working simultaneously, you will need to merge Update Sets before promoting to production. The merge process combines all changes into a single Update Set.

// Best practice: always merge in development order
// Dev Update Set A + Dev Update Set B → Merged Update Set
// Then promote the merged set through test → production

Merge in the order changes were made. Merging out of order can cause later changes to be overwritten by earlier ones.

Common Problems and Fixes

Update Set shows "No Records" after import

The XML file is corrupted or the import failed silently. Re-export from the source instance and reimport.

Changes don't appear after commit

The Update Set committed but the changes are on a different application scope. Check that the target instance has the same application scope active.

Scheduled job runs immediately after commit

Scheduled jobs in Update Sets retain their run time from the source instance. Review all scheduled job next run times after committing.

Best Practices

• One Update Set per feature or bug fix — not one giant set for everything
• Name Update Sets descriptively: INC-1234 Fix assignment logic for P1 incidents
• Never modify production directly — even emergency fixes should go through an Update Set
• Keep a record of all Update Sets and their contents in your change management process
• Test the rollback procedure — know how to revert an Update Set before you need to in an emergency