Is anyone validating discovery data before it reaches the CMDB?

[jrbockrath]

Curious how others are approaching this.

Most discussions focus on Discovery, IRE, transform maps, and reconciliation after data enters the CMDB.

I'm interested in what happens before that.

Are teams validating things like:

• duplicate identifiers
• conflicting discovery sources
• CI classification
• source authority
• stale records
• hostname collisions

before the data ever reaches ServiceNow?

Or is that generally handled downstream through IRE, transforms, and cleanup?

I'd love to hear how people are thinking about this.

[Nishant8]

Hello @jrbockrath , Before ingesting data into ServiceNow, initial planning typically covers which types of devices to discover, how to discover them, connectivity with the source system, and port configurations/scans etc. The initial planning phase also includes deploying the MID Server and establishing communication with ServiceNow and the discovery sources. Common ingestion methods include Discovery, Service Mapping, and Service Graph Connectors.
When inserting data into the CMDB, the Identification and Reconciliation Engine (IRE) plays a critical role in maintaining data integrity. As you mentioned, identification rules handle duplicate identifiers, CI classification, and hostname collisions (if configured to do so). Meanwhile, reconciliation rules manage conflicting discovery sources and data source authority.
Once data is successfully inserted, CMDB data governance policies run periodically to maintain CMDB health through three key metrics: Compliance, Completeness, and Correctness. Correctness addresses stale records, duplicates, and orphan CIs. Data governance covers a wide range of functionality; I have limited my response to directly address your questions.

Regards,

Nishant

[jrbockrath]

Thanks for the thoughtful response. I agree that's how ServiceNow is designed to manage those concerns once data is flowing into the platform.

I think the part I'm curious about is slightly different. In environments with multiple discovery sources, do teams intentionally review and govern the incoming data before it enters the CMDB, or is the expectation generally that IRE, reconciliation, and ongoing governance will sort things out after ingestion?

For example, if a discovery source is producing hundreds of probe-only records, inconsistent classifications, or conflicting identity signals, do most organizations stop and address that upstream, or do they let it enter the CMDB and resolve it there?

I'm less interested in what the platform is capable of and more interested in how mature implementations operate in practice.

[mugi-san]

Hello, @jrbockrath .

While this is based strictly on my personal experience with the case,

we first verified what kind of CMDB identification rules were necessary,

and then implemented those rules before starting the discovery.

As others have already pointed out,

there are actually other perspectives to consider as well.

Actually, it’s usually resolved by combining pre- and post-processing.

Depending on the circumstances, we should look into the points you raised, regardless of ServiceNow.

Regards,

[jrbockrath]

Thanks, that's helpful and aligns with what I've been wondering.

The combination of pre- and post-processing seems to be where mature implementations end up. What I'm trying to understand is where people draw that line in practice.

For example, are there certain issues that you would always resolve before ingestion—such as obvious identity conflicts, poor classifications, or low-confidence records—because they're easier to govern upstream? Or do you generally prefer to let those reach the CMDB and rely on IRE and downstream governance to sort them out?

I'm interested in the operating model more than any specific ServiceNow feature.