Stop Auditing, Start Fixing
Let’s be honest. At some point, you’ve run ServiceNow’s Instance Scan. You waited for the results, opened the dashboard, and saw a number so high – 20,000, 50,000, maybe more – that you just quietly closed the tab.
You’re not alone.
We all know our instances have… let’s call it “historical charm.” Technical debt. Customizations from 2014 that nobody dares to touch. Instance Scan is the tool that shines a bright, unforgiving light on all of it. But here’s the thing: most people treat it like an audit, which is why they fail. An audit is something you survive. It’s a judgment.
You have to change your mindset. Instance Scan is not an audit tool; it’s a backlog generator.
Its purpose isn’t to make you feel bad. Its purpose is to feed your development teams with small, manageable, and prioritized tasks that make the platform healthier over time. If you just run it once, get scared, and ignore it, you’ve missed the point.
The secret isn’t in the scan; it’s in the loop.
Insights provided by:
Bjarne Steen Nielsen
Partner & ServiceNow Certified Master Architect
Building a Sustainable Loop (How to Actually Do This)
You need a repeatable process, not a one-time project. It’s a simple cycle that turns that mountain of findings into small, manageable hills.
First, you need a rhythm. Stop running one-off scans when you’re “curious.” That’s a recipe for being overwhelmed. Go to the scheduled job Trigger Full Scan and set it to run automatically. How often? A good starting point is once every four weeks, or maybe every two, running over the weekend. The goal is to get a consistent, regular pulse of your platform’s health.
Next comes triage. This is the most critical part. When the scan finishes, findings land in the Scan Finding [scan_finding] table. A finding without an owner is just noise. Your first job is to get them to the right people. You can set up assignment rules to send findings to the right teams. If you don’t have dedicated teams, assign them all to a central group (like your platform owners). Someone must be responsible for looking at the list.
Once they’re assigned, you prioritize. You will have thousands of findings. You cannot fix them all. Don’t even try. Look at your Priority 1 and Priority 2 findings first. What are these?
Critical security issues: Missing ACLs, insecure script includes.
Major performance killers: Bad GlideRecord queries in loops.
Upgrade-busting code: Anything that is guaranteed to break.
Ignore the “low priority” stuff for now. You’re not boiling the ocean; you’re just putting out the biggest fires.
For every finding you analyze, you have three choices: Fix, Mute, or Resolve.
Fix means the finding is real, it’s bad, and it needs work.
Mute is a powerful, underused feature. This means the finding is real, but you are consciously accepting the risk. It cleans up your dashboard and tells the tool, “Thanks, I know. Stop flagging this.”
Resolve is for false positives or issues that are already fixed.
Finally – and this is how you complete the loop – if a finding needs a fix, you turn it into work. Don’t just jump into a sub-prod and start coding. Use the “Create Story” (or Task, or Defect) button right on the finding form.
This is the magic. It takes that abstract “finding” and turns it into a real, tangible piece of work. It gets added to the responsible team’s backlog. It can be prioritized, sprint-planned, and tracked just like any other bug or feature request.
Now, the work is no longer a simple cleanup; it’s a formal, visible part of your development lifecycle.
Why Bother? This Isn't Just "Cleanup"
This isn’t just about “clean code” or making a dashboard look green.
This process is about speed and safety. Every high-priority finding you fix is one less “gotcha” during your next upgrade. It’s one less P1 incident caused by a runaway script. It’s one less security hole waiting to be found.
Don’t let the tool just be an auditor. Use it as a development-planning engine. Run the scan, assign the findings, analyze the priorities, take action, and create the stories. Then do it all again next month. That’s it. That’s the whole process.
Make It Your Engine, Not Your Judge
The biggest mistake is waiting for the “perfect time” or for your backlog to be empty. That time will never come. Start using Instance Scan now. But don’t just run it once. Build the sustainable loop we just described. Build a real system around it. Make it actionable, make it accountable, and make it a core part of how you manage the platform.
Once you have that system, you can take it to the next level. Automate Instance Scan with the brand new ServiceNow Release Ops functionality. By doing so, you make these scans a non-negotiable, automated gate in your CI/CD pipeline, not just a monthly chore.
And if you’re still staring at that 50,000-finding dashboard and don’t know where to start? Call us. This is what we do. We’ll help you cut through the noise and turn that mountain of technical debt into a prioritized, manageable, and automated engine for platform health.
