- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
yesterday
Hi there,
Big change you've seen or even had to deal with the official ServiceNow HealthScan Scorecard at customers. The "ServiceNow HealthScan Scorecard provides an automated review of an instance". The PDF document optionally is accompanied with an Excel file pointing to all findings in detail.
While I'm not a fan of the HealthScan at all, I do feel the need to dive into some of the findings and share learnings I encounter at every single customer. In a few articles I will try to give a bit of explanation on findings, what you can do to solve them, and perhaps what you can do to prevent them in the first place. Some of the findings are solid gold, some of them are…
The first articles in this series will be a bit cherry picking, and then slowly progressing to more complex or time-consuming findings. Starting with the easy to solve findings to improve scores quickly and with minimal effort. Scores that often people in decision making places are sensitive to. Later on diving into more complex or time consuming findings, which are way more interesting for genuine developers.
Topics in this series of articles (I will update this section when publishing new articles):
- Update Sets should be named uniquely
- Use Notification Categories
- Populate Knowledge Base articles fully
- Report shared with a group which has no users
- Differs from baseline
- ...
HealthScan
"ServiceNow HealthScan Scorecard provides an automated review of an instance, to better understand instance health. HealthScan Scorecard uses a pre- defined library of best practice called definitions to inspect the instance. Only aggregated information is collected during this inspection scan, which is then analysed and compared. Details such as script names are not collected. The scores reflect alignment to the ServiceNow best practices, and give a high level summary only."
"ServiceNow HealthScan Scorecard is a high level overview of instance health. To get more detailed information, including advice on remediation, please contact the ServiceNow Customer Outcomes team who can advise you of options."
Differs from baseline
One of the definitions within the "Upgradeability" category concerns "Differs from baseline". ServiceNow explains this definition as:
"These *** have been modified from the out-of-the-box baseline. These scripts will not be altered upon an upgrade.
Review the changes to these *** and revert to the baseline version if appropriate. Otherwise, thoroughly test after an upgrade."
A bit limited if you ask me. What matters is not removing all differences, but validating that each customization is intentional and still correct. "Differs from baseline" is simply a signal that deserves review: some changes are essential, others are outdated, and a few are accidental. Recognizing which is which helps ensure your platform remains healthy and upgrade-ready.
Identifying findings
The optional detailed Excel file provided with the ServiceNow HealthScan Scorecard will list all records identified as findings for this definition. Also links are included that take you to the findings in your instance directly.
How ServiceNow exactly determines the findings, I can't tell. Those details are not shared. What I can imagine though, (scripted) checking specific tables if any of its records (even if they are active is false!) have been updated other than by an Upgrade / Patch / Hotfix / Store update.
If you do not have the detailed Excel file, you could try to identify them by running the below script, or my first go to: Instance Scan 😀.
Out-of-the-box API
SncAppFiles.hasCustomerUpdate(object)
Table Check
The Table Check above is one of the seven out-of-the-box Table Checks that were shipped in earlier versions of Instance Scan. I've extracted them, removed the protection policy, and sharing them here as download. It concerns Table Checks for:
- Differs from baseline: Business Rules
- Differs from baseline: UI Pages
- Differs from baseline: UI Actions
- Differs from baseline: UI Macros
- Differs from baseline: Script Includes
- Differs from baseline: Client Scripts
- Differs from baseline: UI Scripts
- Differs from baseline: Email Scripts (custom)
Resolving findings
Having all findings available, we can start working on resolving them. How to resolve them is really up to you. Personally I would focus on:
- "No differences found", okay cherry-picking
Somehow these records are recognized as being customized, "you touch it you own it". Just resolve these ones, revert to baseline.
- Records that have been deactivated
For rightful requirements within your company, just ignore these.
- Records that were customized a while ago
Does the requirement for customization still stand? Or is this outdated and needs to be reversed/revised/merged?
Definitely not an easy task, and one that can be time-consuming or... one you can't fulfill because of risks, technical depth, etcetera.
Preventing findings
While resolving “Differs from baseline” findings can be time-consuming, preventing new ones is surprisingly easy once teams understand how they’re created. Most findings are not caused by deliberate customization at all, but by someone opening an out-of-the-box record, hitting Save, or making a tiny change that seemed harmless at the time.
Here are a few ways to prevent new findings in the future:
- Avoid modifying out-of-the-box artifacts unless absolutely necessary
The platform often allows you to extend or override behavior without editing the original record. Create new Script Includes instead of editing out-of-the-box ones, add new UI Actions rather than modifying existing ones, and prefer configuration over code where possible.
- Don’t save out-of-the-box records unless you genuinely intend to customize them
A record marked as "No differences found" but still flagged is almost always the result of a save action. Remind developers that saving means owning the record going forward, "you touch it, you own it".
- Keep an eye on older customizations
Requirements change, the platform evolves, and what was once a justified customization may no longer be necessary. Periodic review helps keep technical debt down and avoids inherited findings in the future.
---
That's it. Hope this helps you identifying, resolving, and preventing HealthScan findings. If any questions or remarks, let me know!
| C |
If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.
Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? |
Kind regards,
Mark Roethof
Independent ServiceNow Consultant
10x ServiceNow MVP
---
