ServiceNow Instance Scan: What It Is and How to Use It

Acting on Instance Scan findings

Instance Scan is most valuable when findings lead to remediation, not just a report. For each finding category, build a remediation backlog: prioritise findings by impact (performance findings on high-traffic tables first), assign owners (the developer who built the script is the best person to fix it), and track progress. Set a target of addressing all Critical and High findings within 30 days of each scan run, and Medium findings within 90 days. This cadence keeps technical debt from accumulating faster than you can address it.

Common remediation patterns: for "GlideRecord without limit" findings, add gr.setLimit(500) and convert to paginated batching if the operation processes more than 500 records. For "GlideRecord COUNT" findings, replace the loop with GlideAggregate. For "Script Include not in scope" findings, move the Script Include to the correct application scope. For security findings, review with a developer and security architect together — security finding remediation often requires understanding the intent of the original implementation before choosing the fix.

Related: GlideRecord performance · GlideAggregate · ACLs · Slow instance troubleshooting

Creating Custom Scan Checks

The real power of Instance Scan is the ability to write custom checks tailored to your organisation's standards. A check is a Script Include-like script that queries the instance and returns findings. Custom checks follow the same structure as platform-provided ones: define the target table, specify the query condition that identifies violations, and provide a remediation recommendation. For example, an organisation that mandates all Business Rules have a comment explaining their purpose could write a check that queries sys_script for records where the description field is empty. This check runs in seconds and surfaces every undocumented rule in the instance.

Scan Categories and Prioritisation

Instance Scan organises checks into categories: Performance, Upgrade Readiness, Coding Best Practices, and Security. Each category contains multiple individual checks, and each check produces findings ranked by severity — High, Medium, or Low. In a mature instance, the first full scan typically returns hundreds of findings. The practical approach is to prioritise High severity findings in the Performance and Security categories first, then work through Coding Best Practices findings during normal development cycles rather than attempting to remediate everything in a single sprint. Many Low-severity findings in a legacy instance represent historical decisions that are not worth changing unless the affected component is being actively modified.

Integrating Scan into Development Workflow

Instance Scan is most effective when integrated into the development workflow rather than treated as a periodic audit. The pattern that works best is running a targeted scan against the tables and scripts being modified as part of a change, before that change is promoted to the Update Set for deployment. This catches issues while the context is fresh and before the code is in a shared environment. In teams using CI/CD pipelines with the ServiceNow DevOps tools, Instance Scan can be triggered automatically as part of the pipeline, blocking deployment if High severity findings are introduced.

Scan Results and Technical Debt Tracking

Scan results are stored in the scan_finding table and can be queried, exported, and tracked over time. Building a simple dashboard using Performance Analytics or a Reporting widget to track finding counts by category and severity over time turns Instance Scan from a point-in-time audit into a technical debt metric. Trending the number of High-severity findings over quarterly intervals gives platform managers an objective measure of instance health that is useful in conversations about technical debt remediation investment. The GlideAggregate guide covers the query patterns needed to build these aggregate metrics from the findings table.

Common High-Impact Findings

Several check categories consistently produce the highest-impact findings across enterprise instances. Synchronous Business Rules performing GlideRecord queries without limits are flagged because they can run unbounded queries against large tables during record operations. Scripts using gr.query() inside loops are flagged for the N+1 query anti-pattern that degrades performance under load. ACL scripts that call gs.hasRole() on every record evaluation in a large query are flagged because the repeated role checks add up to significant overhead. The debugging guide covers how to investigate and fix the most common of these patterns.

Scan as a Code Review Tool

Instance Scan can function as an automated code review step when integrated into development practices. After writing a new Business Rule or Script Include, running Instance Scan against the specific table or script type provides immediate feedback on common problems before the code reaches peer review. This shifts quality control left in the development process — catching the "GlideRecord inside a loop" problem before it is in a completed Update Set is far less disruptive than catching it after deployment. Configure a custom scan check for any organisation-specific coding standard that the platform's built-in checks do not cover, turning your internal guidelines into automated enforcement.

Exporting Findings for Governance Reporting

Instance Scan findings stored in scan_finding can be exported and reported on using the standard reporting module. A scheduled report that emails a weekly findings summary to the platform team and their management provides visibility without requiring anyone to actively check the scan results. For organisations with formal technical debt governance processes, exporting findings to a Performance Analytics data source and tracking the trend line over time provides the quantitative measure needed for investment conversations. A platform with 200 High-severity findings trending downward to 50 over six months tells a clear story about the impact of technical debt remediation work — something that is very difficult to communicate with only anecdotal evidence.

Suppressing False Positives

Instance Scan findings are not always legitimate problems in context. A scan check that flags Business Rules without descriptions will correctly find undocumented rules, but it may also flag intentionally minimal rules where a description would add no value. ServiceNow provides a Finding Suppression mechanism that marks specific findings as accepted, with a reason and an expiry date. Suppressions should be used sparingly and with documented justification — they are visible in the suppression audit trail and can be reviewed. Blanket-suppressing entire check categories defeats the purpose of scanning. Use suppressions for specific findings that have been reviewed by a senior developer and determined to be false positives or accepted technical debt, not as a way to reduce the finding count on a report without addressing the underlying issues.

Scan in Update Set Validation

The most impactful Instance Scan integration is running it automatically against artifacts in an Update Set before promotion. By targeting the scan at specific sys_ids modified in the Update Set, you can surface issues introduced by the current change rather than reporting on the entire instance's technical debt. This targeted approach is faster than a full instance scan and provides the feedback at the decision point — the approver reviewing the Update Set gets scan results alongside the code changes. Implementing this as part of a release gate process means High-severity findings block promotion until addressed or formally accepted, creating a quality control checkpoint that operates without requiring manual review of every change.