Connect a new discovery source to ServiceNow and the first thing it often does is create a second record for a server you already have. Same physical host, different hostname format, no link between the two. Nobody notices until a change ticket references the old record and a technician provisions against infrastructure that was decommissioned six months ago.
That isn't a connectivity failure. The API worked exactly as configured. The problem sits in the data on either side of it, and no integration ever built has fixed that on its own.
Large estates run on more systems than any one dashboard can show: cloud accounts, on-premises data centres, monitoring tools, and asset registers that were never designed to agree with each other. Connecting them through a ServiceNow integration is meant to pull that into one place. Done properly, it gives platform owners genuine visibility into hybrid infrastructure, faster incident routing, and fewer manual record updates.
Done without ingestion controls, it does something else. It moves bad data between systems more quickly than a person ever could, because the configuration management database (CMDB) at the centre of it has no way to tell a new record apart from a duplicate on its own. Every additional source added to the pipeline multiplies whatever inconsistencies already existed.
Every organisation running multiple discovery feeds into ServiceNow sees the same failure patterns:
On paper, the environment looks connected. In practice, none of it can be trusted enough to automate against.
ServiceNow has native controls built for exactly this problem, and most integrations that fail simply aren't using them.
Service Graph Connectors standardise data at the point it enters the CMDB, rather than leaving each integration to invent its own mapping. The Identification and Reconciliation Engine (IRE) applies identification rules before a new record is allowed to merge with an existing one, which is what actually stops duplicates rather than catching them after the fact. Multisource CMDB retention keeps the raw data from each feed separately, with visible lineage, so a platform owner can see which source claimed what before the records were merged.
Used together, these give platform owners a CMDB 360 view precise enough to audit the ingestion pipeline itself: which source is creating duplicates, which fields keep conflicting, and where reconciliation rules need tightening before the next discovery run makes it worse.
The cost of ignoring this doesn't stay theoretical for long.
Infrastructure that never resolved to a clean CMDB record stays invisible to vulnerability scanners, which is how unpatched systems survive in estates that technically run continuous scanning. Incident teams lose time to manual triage when the relationship data linking a failing component to the business service it supports doesn't exist, which is one of the biggest drivers of a slow mean time to resolution (MTTR). Auditors reject configuration data that doesn't match the physical estate. And change managers approve changes against partial information, because the risk assessment is only as complete as the dependency data behind it.
Each of those traces back to the same root cause: an integration that was never checked against what it was actually putting into the CMDB.
Most organisations that notice this run a clean-up project: a few weeks spent de-duplicating records and closing gaps. It works, briefly. Then cloud resources scale, a new discovery feed goes live, and the same categories of error start accumulating again, because the clean-up fixed the data and left the process that produced it untouched.
Sustainable CMDB data quality needs the same discipline applied continuously: a named owner for each class of configuration item, reconciliation rules reviewed on a schedule rather than after an incident, and a change gate that checks new integration sources against identification rules before they're allowed to write to production data.
We run a discovery and integration coverage review that establishes what's actually missing from an estate's ServiceNow data, where the gaps sit, and what they cost during an incident or an audit. It covers both horizontal discovery and third-party tool integration, and the output tells a platform owner exactly which integrations are trustworthy enough to automate against and which ones need reconciliation rules fixed first.
The same physical host can arrive with a different hostname format and no link to the existing record. Without ingestion controls, the CMDB has no way to tell a new record apart from a duplicate on its own.
They standardise data at the point it enters the CMDB, rather than leaving each integration to invent its own mapping.
It applies identification rules before a new record is allowed to merge with an existing one. That stops duplicates rather than catching them after the fact.
Infrastructure that never resolved to a clean CMDB record stays invisible to vulnerability scanners. That is how unpatched systems survive in estates that technically run continuous scanning.
It fixes the data and leaves the process that produced it untouched, so errors start accumulating again when cloud resources scale or a new discovery feed goes live. It needs a named owner per class, scheduled review of reconciliation rules and a change gate for new sources.
Written by Warren O'Neill, Apex Configuration Group.