We should all be leveraging Instance Scan more, it saves hours during code reviews.

[ChrisF323949498]

I think Instance Scan is probably one of the underused features of ServiceNow, and it's so powerful and useful.

If you've worked in 'Software dev teams' (E.g. Teams whom are building web apps in ReactJS, etc) then lint scans and security scans are the norm before deployments, however I see this less often in the ServiceNow space and this is where Instance scan can help you.

The docs can be found here for this tool, but in short, it lets use scan Apps, individual files, and Update Sets, amongst others.

This is a huge time saver, if you are constantly reviewing code before release and I would encourage you to spend 1 hour today looking at it, it's saved me weeks of effort.

Leverage the out of box checks immediately

ServiceNow out of the box ships with numerous (260+ and counting) checks, these are categorised across

1. Manageability
2. Security
3. User Experience
4. Performance
5. Upgradability

and the categorise have no real functional impact, except that they help categorise the findings when its time to check the results of your scan, similarly too for Priority.

Create your own custom checks to save hours

Coming back to the intro example, I can create this custom check to look for logging and Instance scan will let me know if it finds a result.

This leverages a 'script only check' and the code that can be used is as follows

(function (finding, columnValue) {
	let logStatements = columnValue.match(/gs\.log\s*\(/g);

	if (logStatements) {
            logStatements.forEach(function(foundOne) {
                    finding.increment();
            });
	}
}) (finding, columnValue);

This script will be given the column value from the files you are scanning, then it checks that column value for a gs.log and if it finds it just uses the provided 'finding' to increment the count (this just tells the platform to log a result, and the result is linked to the record!)

Now I just need to run this against an update set, check the results, and if I begin to build out further checks then code reviews become a lot more efficient! 

In future blogs I'll aim to document the functions/methods we have access too as they're not documented in as much depth as they could be, and there are some gems you can utilise in any custom checks you create.

I hope this saves you as much time as it did for me!
Have a great day!

[Dan Covic2]

I completely agree with your point.

That said, I feel it doesn’t fully capture the broader picture or reflect the full potential of this tool.

When using the AEMC CI/CD pipeline for deployments (e.g., from DEV → TEST → PROD), and allowing ATF tests and Instance Scan checks to run automatically, several important questions come up:

• When the system writes or detects Instance Scan and ATF test results in the Deployment Environment Result table during a deployment request:
  → What is the expected process for handling these findings or errors?
• What is the out-of-the-box (OOTB) functionality for managing such results?
• Should findings/errors be addressed in TEST first, or should they be resolved in DEV?
• And once resolved, should the change or application be redeployed through the pipeline to validate that the issues have been properly handled?

These are critical considerations for ensuring a smooth, traceable, and compliant deployment process.

In my view, the current **Pipelines and Deployments workflow documentation (version 24.1.2) does not adequately address these aspects. Specifically, it lacks clarity on:

• How Instance Scan and ATF test results are handled once recorded in the Deployment Environment Result table.
• What the OOTB process is for managing and responding to these findings.
• Whether the resolution process should begin in TEST or DEV, and how that ties into the pipeline flow.

This documentation gap makes it difficult to fully understand and leverage the tool’s capabilities in a structured and compliant way.

I'd appreciate your feedback or recommendation

** https://www.servicenow.com/docs/bundle/yokohama-application-development/page/build/pipelines-and-dep...