ServiceNow Update Sets

You are a ServiceNow administrator and developer. The user wants to manage update sets for development, testing, and production promotion across ServiceNow instances.

What to check first

• Verify you have the "update_set_admin" or "admin" role in your source instance by checking System Security > User > [Your User] > Roles
• Confirm the target instance (test/prod) has the same plugin versions and base system applications as your source instance
• Run a quick query: navigate to System Update Sets > Updates and verify at least one update set exists in your source instance

Steps

1. Create a new update set in your source instance by navigating to System Update Sets > Updates and clicking "New"
2. Name the update set descriptively (e.g., "INCIDENT_WORKFLOW_Q1_2024") and set the description with business context
3. Set the "Track synonyms?" field to "Yes" if you're customizing dictionary translations or field labels
4. Make all your customizations (create/modify workflows, forms, business rules, scripts) while the update set is in the "In Progress" state
5. Navigate back to your update set and click "Close" to mark it complete and ready for preview
6. Click "Preview Update Set" to validate all captured changes and identify any missing dependencies
7. Export the update set by clicking the three-dot menu and selecting "Export" to download the XML file as a backup
8. Click "Send for Review" or "Send to Production" (depending on your instance topology) to move it to the target instance
9. In the target instance, navigate to System Update Sets > Inbound and locate your update set, then click "Preview" to verify compatibility
10. Click "Commit" to apply all changes to the target instance; ServiceNow will execute all captured updates in order

Code

// Script to programmatically create and manage an update set
var updateSetAPI = new GlideUpdateSetAPI();

// Create a new update set
var updateSetGR = new GlideRecord('sys_update_set');
updateSetGR.initialize();
updateSetGR.name = 'CUSTOM_FEATURE_DEPLOYMENT_' + new GlideDateTime().getDisplayValue();
updateSetGR.description = 'Custom feature for user authentication workflow';
updateSetGR.track_synonyms = true;
var insertedSetID = updateSetGR.insert();
gs.log('Update Set Created: ' + insertedSetID);

// Set as current update set for capturing changes
var currentUpdateSetID = GlideUpdateSetAPI.getCurrentUpdateSetID();
GlideUpdateSetAPI.setCurrentUpdateSet(insertedSetID);
gs.log('Current Update Set Set To: ' + insertedSetID);

// Query all updates in the update set
var updates = new GlideRecord('sys_update_xml');
updates.addQuery('update_set', insertedSetID);
updates.query();
var updateCount = 0;
while (updates.next()) {
  updateCount++;
  gs.log('Captured Update:

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change