Andrew Barnes

5 minute read

Instance Scan

Sometimes a feature or product sneaks up and surprises you with the depth it provides. Instance Scan is one of those sleepers in Quebec release for me. If you check out our Live Coding Happy Hour session, you will see some of what I mean. The scanning engine provides tools to check for opportunities to improve the health of your instance. The earlier you can present those to the developers, the faster and easier it is to align to those organizational practices to help keep your instance running smoothly and maintainable.


We will cover these in some detail, but the image above gives you some idea of the structure. Checks are the building blocks of the evaluations. Checks can be grouped into suites, which can include suites as well. When a scan, which is one of many checks/suites, is run, any checks that find something that needs to be reviewed is called a finding.

Scan Results

Jumping right to the end, let us look at the result of a full scan, which runs all the active checks, and presents its findings in the scan results dashboard.


You can observe I have 183 findings at the top of my findings dashboard. A finding is when a check has found a record that violated the rule outlined in the check. Opening up one of the findings, we can see all the details to help understand the finding.


On the finding record, you can observe the check, the record in question, as well as the description and suggested resolution details. It is here on the finding that you can then choose to mute the finding or create a scan_task record to be assigned to remediate or further investigate the finding. If you mute the finding it will no longer show cause a finding for that check against that target until the finding is unmuted.



Saving the best for last, perhaps, sounds like something I would do! The checks are where the power lies. There are four types of checks:

  • Table - Used to check for specific record conditions on specific tables - will dive into how this is powerful.
  • Column - Used to check for all records with the same column field type. Powerful to allow for checks that are not table specific but instead should be for all fields of that type. URL field requiring some formatting, a string field not having some specific content. So much power hidden here.
  • Script Only - More typical for developer centric checks. These can be used to validate using valid API calls, and following good practices set from your organization.
  • Linter - Similar to the Script checker, but aware of the code syntax so you can identify that the API call that should not be in use is commented, thus not requiring a finding.

All four of the check types can help developers, but as you can see from the table and column type checks, the engine isn’t limited to just things developers care about. A table check example could be something like - active tasks being assigned to an inactive user. I hope that sparked some thoughts on how quickly this will become powerful outside of development time. It opens up to a broader range of user experience, performance, security, and manageability of your instance.


So, you have made some checks, bundle them into suites and think ‘what now?’. Well that’s where the fun begins. The ways to run scans are numerous and each have the right time and place to utilize them. A full scan can be run against the whole instance to level set, followed by scheduling full scans so that the instance administrators can see monitor the Average Findings over time and identify when they need to take action.


A full scan should be done prior to any upgrade, and following it, along with any testing. Doing so in this manner will allow for pinpointing if a finding is a result of the upgrade.

Point scans, a targeted single record scan, can be run directly via a UI Action on the record. It can also be run in a more automated manner like on record update, or commit to source control, etc. You can see how this could be used to give very fast feedback right to developers while they are actively developing.

API and update set based scans can really start to help improve the dev->release process by surfacing findings early in the process so they can be addressed during the development window. Completion of an update set or commit to source control are great times to invoke automated scans of the development and add to your already existing code-review and testing process before development moves up the instance stack.


I am excited about how many doors this opens to help identify and remediate instance health and development issues. I look forward to seeing the ways the scan engine is leveraged that I have not even thought of yet. Adding Automated Testing Framework & Instance Scan together with the CICD spoke/APIs can really elevate the maturity of your ServiceNow practice. Let us know how you are or hope to leverage it in the comments below.