CIs being evaluated is not the same in CMDB Workspace Health Dashboard

FriendlyDude
Tera Contributor

Hi,

 

Back when we are still CMDB Health Dashboard in Washington DC to Monitor triple Cs, we are getting the same number of CIs being evaluated for each KPI. However, in Yokohama we are now encouraged to use CMDB Workspace to monitor triple Cs. I can see that the number of CIs being evaluated is different for each KPI. What could be the explanation for that?

 

JerichoEdora_0-1754478805355.png

 

1 ACCEPTED SOLUTION

AJ-TechTrek
Giga Sage
Giga Sage

Hi @FriendlyDude ,

 

Root Cause & Explanation:
In Washington DC and earlier, the CMDB Health Dashboard used a common CI evaluation scope across all three KPIs — meaning all CIs from the configured health inclusion rules were evaluated uniformly across Completeness, Correctness, and Compliance.
However, starting in Yokohama, with the transition to CMDB Workspace, each KPI now:
Evaluates CIs independently
 Based on its own health metric rules and CI applicability
 Applies different filters or applicability conditions per metric under the hood

 

What This Means:

 

KPI CI Count Difference Reason
Completeness Only includes CIs where mandatory fields (like name, serial number, etc.) are expected and measurable
Correctness CIs must have detectable data accuracy issues (e.g., duplicates, orphaned records)
Compliance Only evaluates CIs against configured policies or internal standards (e.g., OS version, patch levels)

 

Thus, even if all 3 KPIs appear to evaluate the same class (like cmdb_ci_computer), the actual CIs they each process may differ.

 

Suggested Actions:


1. Review the Health Metric Definitions:
* Navigate to: CMDB Health > Metric Definitions
* Check each metric’s filter conditions and applicability rules.
* Pay attention to Exclusion Rules, especially for user-defined classes or specific CIs.


2. Check the Health Inclusion Rules:
* Navigate to: CMDB Health > Health Inclusion Rules

* Make sure CIs are included consistently if that’s the desired behavior.


3. Use the Triple C Monitor Page:
* In CMDB Workspace, use the Triple C Monitor view
* It gives better visibility into why CIs are excluded for certain KPIs.

 

Additional Notes:
* This behavior is by design in Yokohama onwards to give more granular and meaningful CI evaluations.
* If you want to revert to consistent CI evaluation across KPIs, you'd need to align filters and applicability for each metric manually — not generally recommended unless for a specific use case.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

View solution in original post

2 REPLIES 2

Mark Manders
Mega Patron

And which was/is wrong? Have you checked on the logic that is generating those numbers as output?


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

AJ-TechTrek
Giga Sage
Giga Sage

Hi @FriendlyDude ,

 

Root Cause & Explanation:
In Washington DC and earlier, the CMDB Health Dashboard used a common CI evaluation scope across all three KPIs — meaning all CIs from the configured health inclusion rules were evaluated uniformly across Completeness, Correctness, and Compliance.
However, starting in Yokohama, with the transition to CMDB Workspace, each KPI now:
Evaluates CIs independently
 Based on its own health metric rules and CI applicability
 Applies different filters or applicability conditions per metric under the hood

 

What This Means:

 

KPI CI Count Difference Reason
Completeness Only includes CIs where mandatory fields (like name, serial number, etc.) are expected and measurable
Correctness CIs must have detectable data accuracy issues (e.g., duplicates, orphaned records)
Compliance Only evaluates CIs against configured policies or internal standards (e.g., OS version, patch levels)

 

Thus, even if all 3 KPIs appear to evaluate the same class (like cmdb_ci_computer), the actual CIs they each process may differ.

 

Suggested Actions:


1. Review the Health Metric Definitions:
* Navigate to: CMDB Health > Metric Definitions
* Check each metric’s filter conditions and applicability rules.
* Pay attention to Exclusion Rules, especially for user-defined classes or specific CIs.


2. Check the Health Inclusion Rules:
* Navigate to: CMDB Health > Health Inclusion Rules

* Make sure CIs are included consistently if that’s the desired behavior.


3. Use the Triple C Monitor Page:
* In CMDB Workspace, use the Triple C Monitor view
* It gives better visibility into why CIs are excluded for certain KPIs.

 

Additional Notes:
* This behavior is by design in Yokohama onwards to give more granular and meaningful CI evaluations.
* If you want to revert to consistent CI evaluation across KPIs, you'd need to align filters and applicability for each metric manually — not generally recommended unless for a specific use case.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025