Every ServiceNow upgrade carries a tax. Not in licensing, not in downtime, but in the post-upgrade labor of reviewing skipped records: the customized records that conflict with base system changes and must be adjudicated before your instance is truly clean. For organizations with mature, heavily configured instances, that tax can run into hundreds of hours across a release cycle. Automated Skip Resolution is the ServiceNow capability designed to dramatically reduce that burden.
Introduced in the Vancouver release and significantly expanded in Xanadu, Automated Skip Resolution uses configurable rules to evaluate skipped records immediately after an upgrade, patch, or hotfix and take predefined actions on the ones that meet your criteria. What once required a team working through a spreadsheet can now be reduced, in some cases, to a handful of records genuinely requiring human judgment.
What Is a Skipped Record?
To understand Automated Skip Resolution, it helps to first understand the problem it solves. When ServiceNow upgrades a platform, it attempts to apply changes to its out-of-the-box records. If your team has customized one of those records, and the base system wants to modify it at the same time, a conflict arises. ServiceNow's resolution is to "skip" the record rather than overwrite your work, and it logs that skip in the sys_upgrade_history_log table for your team to review.
Each skipped record carries a priority rating from P1 through P5. P1 records (shown in red) represent the highest-impact conflicts, typically involving core platform functionality, while P5 records (shown in green) are the lowest risk. In practice, P4 and P5 records often represent minor additions or metadata changes from the base system, and they can account for the vast majority of skip volume in a given upgrade cycle. Historically, every one of those records still required a human to open it, evaluate the diff, and make a decision.
Before the Vancouver release, that process was entirely manual. There was no systematic way to apply logic across skips in bulk. Automated Skip Resolution changed that.
How Automated Skip Resolution Works
Automated Skip Resolution operates through a framework called Skipped Record Rules, stored in the sys_upgrade_skipped_record_rule table. Each rule combines a condition set with an action, and rules execute automatically against newly created skipped records as soon as an upgrade completes.
The evaluation flow looks like this: after the upgrade finishes, each active Skipped Record Rule is applied in turn to the new skipped records. Rules evaluate conditions either through a no-code query builder (suitable for most common scenarios) or through script-based logic for more complex requirements. If a record matches the rule's conditions, the designated action is applied. That action can be one of four types:
- Keep My Modifications - retains your customization and marks the base system change as declined
- Revert and Keep Inactive - reverts your customization to the base system version but keeps the record inactive
- Assign to User - routes the record to a specific person or group for manual review
- Apply Tags - labels the record for filtering and batch processing later
Each rule execution appends a comment to the skipped record for audit purposes, and that history is tracked separately in sys_skipped_record_rule_history. Records that no rule matches remain in a "Not Reviewed" state for manual attention. Rules can also be triggered on demand via a "Run Now" option, which is useful for retroactively processing records from a previous upgrade or for testing a new rule against existing data.
ServiceNow ships out-of-the-box Skipped Record Rules with the platform. Vancouver included five rules, all shipped in an inactive state as templates. Xanadu added ten new rules, nine of which are active by default, reflecting a meaningfully more mature approach to automated triage.
The Priority Framework: What to Automate and What to Review
Not all skipped records are equally consequential, and the P1-P5 priority system is the lens through which your automation strategy should be designed. P1 and P2 records represent critical conflicts, often involving functionality central to ITSM processes, integrations, or security-relevant configuration. These records warrant careful human review regardless of how the surrounding record set is handled.
P3 records occupy a middle ground. They may involve meaningful customizations but are not typically tied to core platform behavior. Whether to automate P3 handling depends on the nature of your customizations and the specific record types involved.
P4 and P5 records, where the bulk of the automation value lies, tend to involve base system additions like new fields, updated UI policies, or refreshed catalog content that does not conflict with meaningful custom logic. A well-crafted Skipped Record Rule targeting these priorities can safely handle the majority of your skip volume. The real-world impact can be substantial: in one example, 132 of 136 skipped records generated by a patch were automatically processed by rules, leaving only four for manual review.
Important Considerations Before You Enable Rules
Automated Skip Resolution is a powerful tool, but it carries a risk that is easy to overlook. The most significant concern involves out-of-the-box rules that mark skipped records as "Reviewed and Retained," effectively closing them out without surfacing them for human attention. When a base system upgrade introduces genuinely new and important functionality, a rule that auto-resolves those records can cause your team to miss the change entirely.
Watch out: In Xanadu, ServiceNow added new fields to Service Catalog records as part of base system improvements. An OOB Skipped Record Rule that auto-marks those records as "Reviewed and Retained" can cause teams to miss these additions entirely. Before activating any out-of-the-box rule, review exactly what it targets and what action it takes. Do not assume OOB rules are universally safe to activate without evaluation.
Two additional misconceptions are worth addressing directly. First, the Resolution Status field on a skipped record is a tracking and reporting field. Changing it does not trigger any automated system action; it is informational only. Second, the "Revert" action in Automated Skip Resolution is not captured in update sets. If you revert a customization on your development instance, that reversion must be manually repeated on other instances. There is no automatic propagation.
It is also worth noting that no automated merge action currently exists in the platform. When a record requires a true merge of base system changes with your customizations, that work requires human judgment. The platform can route the record and flag it, but the merge itself remains a manual task.
Getting Started: Practical Guidance
Whether you are approaching Automated Skip Resolution for the first time or looking to mature your existing practice, the following guidance reflects both platform best practices and the hard-won experience of organizations that have worked through multiple upgrade cycles.
- Start in sub-production. Run your first automated resolution pass in a non-production instance. Validate rule behavior, observe edge cases, and capture decisions in an update set before promoting to production.
- Select an update set before you begin resolving. ServiceNow includes a business rule ("Add To Update Set On Resolution Change") that can capture resolution decisions. Make sure an update set is active and selected so those decisions travel with your deployment.
- Review OOB rules before activating them. Go through each out-of-the-box rule in
sys_upgrade_skipped_record_rule, understand what it targets, and confirm the action is appropriate for your environment. Activate rules deliberately, not wholesale. - Focus manual effort on P1 through P3. Reserve human review time for the records that actually warrant it. Let well-designed rules handle P4 and P5 volume so your team's attention is spent on meaningful decisions.
- Review skips promptly after each upgrade. Do not allow skipped records to accumulate across release cycles. The longer they sit unresolved, the harder it becomes to understand the original intent of the customization and the more complex the resolution decision becomes.
- Build custom rules for your environment's patterns. OOB rules are a starting point. Over time, if you observe recurring categories of low-risk skips specific to your instance configuration, create rules to handle them automatically. Document the reasoning in comments on each rule for institutional knowledge.
- Track your skip volume over time. If the number of skipped records is growing from upgrade to upgrade, that is a signal. It likely means customizations are accumulating in areas that are actively evolving in the base system, and the longer-term answer is configuration over code where possible.
The goal is not to automate everything. It is to automate the obvious decisions consistently and confidently, so the team's judgment is applied where it genuinely makes a difference.
Where This Fits in the Broader Upgrade Workflow
Automated Skip Resolution is one phase within the Guided Upgrade Console, ServiceNow's end-to-end framework for managing platform upgrades. The full workflow moves through five stages: Plan, Execute, Auto-resolve, Manual resolve, and Track. Automated Skip Resolution lives in the Auto-resolve phase, operating immediately after execution completes and before your team engages in any manual review.
Understanding that position matters because it shapes how you approach the overall upgrade cycle. The planning phase is where you proactively minimize future skip volume by favoring configuration over customization. The execution phase runs the upgrade itself. Auto-resolution handles the bulk of low-risk triage. Manual resolution, now scoped to genuinely complex conflicts, moves faster because the noise has been cleared. And tracking gives you the longitudinal view to improve your rules and reduce skip volume across future cycles.
The net result, when the capability is used well, is an upgrade practice that is more consistent, more auditable, and less dependent on the availability of individual team members to work through a long queue of records. The institutional knowledge that was previously locked in individuals' heads gets encoded in rules, runs automatically, and gets better with each cycle.
Ready to put this into practice?
Start by reviewing the Skipped Record Rules in your sub-production instance and evaluating which out-of-the-box rules are appropriate for your environment. For deeper guidance on the full upgrade lifecycle, explore the ServiceNow Upgrade Center documentation and the upgrade management courses available on Now Learning. Share your experience, questions, or custom rule patterns in the comments below.
