
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 weeks ago
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."
Populate Knowledge Base articles fully
One of the definitions within the "Manageability" category concerns "Populate Knowledge Base articles fully". ServiceNow explains this definition as:
"All KB articles should have an Author and a Valid to date. A recommended practice would be to have a report or dashboard scheduled to find any offenders after this initial clean up is processed."
Out-of-the-box, on new Knowledge the Author and Valid to fields are not mandatory. On the Dictionary Entry the Author has a Dynamic default value set, and the Valid to has an optional scripted default value set. In theory the finding can occur for the Author, although this would be highly unlikely (and on an out-of-the-box Zurich instance, the Author field is also not on the Form layout). The conditional scripted default value for the Valid to field is more likely the cause of this finding, since the value is conditional and the Valid to field is visible on the Form layout and not mandatory.
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:
- Records in table Knowledge [kb_knowledge]
- With a query like:
-- Author is empty OR Valid to is empty
-- Active is true
If you do not have the detailed Excel file, you could identify Notifications that have the Uncategorized Category value in multiple ways. From a list, background script, or my first go to: Instance Scan 😀.
Table Check
One advantage of using a Table Check is that a Table Check ignores out-of-the-box records.
Resolving findings
Having all findings available, we can start working on resolving them. How to resolve them depends a bit on your situation and your process. When it only concerns a hundred findings, you might solve them within 15 minutes by manually updating the value of the Author and the Valid to fields.
Since this isn't considered development, you can apply the correction on the Author and the Valid to fields on your production instance directly.
Preventing findings
Now we can identify and resolve the findings… how about actually preventing new occurrences in the first place? Since in most occurences the Valid to field is the rootcause of these findings, why not change this field to be mandatory by default?
I would suggest updating the mandatory field on the Dictionary entry of the Valid to field, and making the value true.
---
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
---
- 619 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Great breakdown, Mark. I like how you not only explained the HealthScan finding but also showed practical steps to resolve and prevent it. Making the Valid to field mandatory at the dictionary level is a simple yet effective way to avoid recurring issues. Thanks for sharing these insights – looking forward to the next article in the series!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi @Mark Roethof - Great write-up! One suggestion: anchor each finding in its intent. In this case, the focus is user experience, and the goal is to prevent KB sprawl. Over time, many orgs accumulate thousands of stale articles that drown out the good ones and make it harder for users to find what they need.
A practical pattern I’ve seen work:
-
Set a sensible “Valid to” by default (e.g. publish date + 365 days).
- Consider a fix script for initial cleanup.
-
Route expiring items into a review workflow (notify the owner; quick affirm/edit/retire path).
-
Clarify ownership vs authorship (assign a persistent content owner/steward; authors often change roles or leave).
-
-
Allow “evergreen” exceptions sparingly, with justification.