Your update set previewed clean and you're ready to deploy those changes to the target instance. This guide walks you through committing safely, handling errors that surface during commit, and setting up proper rollback procedures.
Why update set commits fail in production
Preview passes don't guarantee clean commits. Previews run against static metadata, but commits execute against live data with active users, running workflows, and changing records. A business rule that looked fine in preview can fail during commit when it hits production data volumes. The people managing these deployments — platform admins and release managers — get pulled into emergency troubleshooting sessions when commits fail halfway through, leaving instances in inconsistent states.
How commits execute and what goes wrong
ServiceNow processes update set commits sequentially, creating each update record one at a time. Unlike previews, commits are transactions that modify your live database immediately. The commit can fail on any individual update record due to data validation, circular dependencies, or missing references that existed in the source but not the target. When a commit fails, ServiceNow stops processing and leaves you with a partially applied update set. The key insight: commits are atomic per update record, not per update set.
Building reliable deployment procedures
Production-quality deployments include commit verification, immediate smoke testing, and rollback procedures ready to execute. After committing, check that your changes work with live data, not just that the commit completed. Most teams add monitoring for the first hour after deployment and keep business stakeholders on standby to validate functionality. The difference between basic and mature deployment processes is having rollback procedures tested and ready before you need them, not scrambling to create them during an incident.
Before you start
- •admin role or update_set_commit ACL access
- •Update set in Retrieved or Previewed state
- •Clean preview with no unresolved errors
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to the retrieved update set
Go to System Update Sets > Update Sets to Commit. Find your previewed update set and click into the record. Verify the State shows 'Previewed' and the Preview Summary shows no errors or conflicts that require resolution.
If you see warnings but no errors, you can commit — warnings won't block the process.
Execute the commit
Click the Commit Update Set button at the top of the form. ServiceNow processes each update record individually and displays progress in real-time. Watch for any error messages that appear during processing — these indicate actual failures, not preview warnings.
Large update sets can take several minutes to commit — don't refresh the page or navigate away during processing.
Review the commit results
Once processing completes, check the State field — it should show 'Committed'. If you see 'Commit Failed', scroll down to the Update Set Preview Problems related list to see which specific update records failed and why. Note the exact error messages for troubleshooting.
Failed commits leave the update set in a partial state — some changes applied, others didn't.
Check the commit log details
Click on the Customer Update Records related list to see every change that was applied. Look for any records with errors or warnings in the Result field. This log shows exactly what ServiceNow created or modified during the commit process.
Save this view as a reference — you'll need these sys_ids if you have to build a rollback update set.
Test the deployed functionality
Don't assume a successful commit means working functionality. Test the actual features you deployed with production data and user scenarios. Check that business rules fire correctly, UI policies work as expected, and integrations still function. Focus on the areas your update set modified.
Test within the first 30 minutes after commit while the deployment is fresh in your memory.
Create rollback procedures if needed
If testing reveals issues, go to System Update Sets > Generate Update Set from Sys IDs. Use the sys_ids from the Customer Update Records to create a back-out update set that reverses your changes. Alternatively, go to the committed update set record and click 'Back out Update Set' to generate an automatic rollback.
Test rollback update sets in a sub-production environment first — they can fail just like forward deployments.
Best practices
Never commit update sets during peak business hours — if something breaks, you need time to fix it before users notice.
Commit failures are irreversible without a back-out update set, so have your rollback plan ready before you click commit.
Large update sets should be split into smaller functional chunks — if one piece fails, you don't lose everything.
Always test committed functionality immediately with real production data, not just verify the commit completed.
Keep business stakeholders informed of deployment timing so they can validate their processes work after your changes.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue