The short answer
A CMDB can report 94 percent completeness and still drive a wrong service dashboard, because completeness only measures whether fields are populated. Correctness and compliance are separate health scores. The usual cause is missing service relationships or duplicate CIs, so a senior answer checks relationships and reconciliation rules before blaming Discovery.
This is the scenario we put to ServiceNow ITOM candidates. It is worth walking through because the trap in it is one real CMDB programmes fall into constantly: reporting a health score that is true and meaningless at the same time.
A client's CMDB reports 94 percent completeness and the executive service dashboard is still wrong. Where do you look, and what do you tell the sponsor?
The trap: completeness is not correctness
ServiceNow's CMDB health model scores three different things. Completeness asks whether the required and recommended fields on each CI are populated. Correctness asks whether the data is right — duplicates, orphaned CIs, stale records. Compliance asks whether CIs conform to the standards the organisation has set for them. A CMDB can score 94 on the first and still be badly wrong on the second.
An executive service dashboard does not care whether fields are filled in. It cares whether the CIs underneath a business service are the right ones, connected the right way. That is a correctness and relationship question, and the 94 percent says nothing about it.
What a senior answer contains
- Separates the three health scores immediately, and asks which one the 94 percent refers to before treating it as good news.
- Goes to relationships rather than CI count. A CMDB full of well-populated CIs with no service relationships between them produces exactly this symptom: every record looks healthy, and the service view built on top of them is wrong.
- Checks the identification and reconciliation rules for duplicate CIs before blaming Discovery. When two sources describe the same server differently, reconciliation decides which record wins. Get those rules wrong and the dashboard counts one server twice, or attaches the service to the stale copy.
- Tells the sponsor plainly that this is a data problem, not a reporting problem. Reconfiguring the dashboard will not fix it, and saying otherwise buys a few weeks before the same conversation happens again.
Where a mid answer stops
- Reports the 94 percent as good news and starts on the dashboard configuration. That is the fastest route to fixing the wrong thing.
- Cannot name the three health dimensions, or say which one the number refers to.
- Proposes re-running Discovery without asking what populated the CIs in the first place. Discovery is often only one of several sources feeding the CMDB, and re-running it does nothing about records arriving from imports or integrations with their own identification behaviour.
The wider point
CMDB programmes are judged by a number that is easy to raise and a dashboard that is hard to make right. Candidates who have only ever been measured on the number tend to optimise it. The ones worth placing have been asked why the dashboard is still wrong, and had to answer.
This is the published screen for servicenow itom developers. The role page carries the scenario, the full rubric and the technologies we screen on.