A CMDB import can finish successfully while producing the wrong CIs: a server lands in a generic class, a trusted owner is overwritten or one cloud instance appears three times. In the ServiceNow CIS-DF ingest domain, Service Graph Connectors and IntegrationHub ETL should be evaluated as controlled transformation paths rather than transport mechanisms alone. A reliable rollout traces a source record through normalization, class selection, identification, reconciliation and the resulting relationships.
A multinational retailer is onboarding an endpoint-management source alongside existing cloud discovery. The first source reliably reports patch status; the second supplies durable cloud resource identifiers. Multisource CMDB governance must state which source owns each CI attribute before reconciliation and mapping rules are deployed. The ingestion test then needs to show one surviving virtual-machine CI, field-level provenance for contested attributes and a repeatable result when either source sends its next update.
Start with a source contract, not a connector menu
Before choosing a connector, define what the source knows well: asset identity, class, relationships, discovery timestamps, lifecycle status and attributes that it owns. Record the population covered and its blind spots. A cloud API may see instances that an on-premises discovery probe cannot, while an endpoint agent may know the operating system but not the business service supported. No single source should silently claim to be authoritative for every CI field.
Write sample source payloads into a mapping contract. For each field, specify destination class and attribute, source identifiers, format conversion, update cadence and what a missing value means. Empty values are particularly dangerous: should the update clear a previously known owner, or does it mean the upstream feed omitted that field? Resolve this question before staging. It is much cheaper to reject a problematic payload than to reconstruct a deleted ownership field from audit history after a bulk load.
Choose the supported integration path deliberately
Service Graph Connectors provide purpose-built integrations for third-party inventories, and API variants can bring data through API-oriented patterns. IntegrationHub ETL supports transformation and mapping for supported ingestion workflows. Evaluate a connector for the actual target source and platform release rather than treating all connectors as identical. A ready-made integration still requires credential setup, class and attribute alignment, health monitoring, release management and source ownership.
A custom API push may be justified when no suitable supported connector exists, but it should still respect CMDB identity and reconciliation through the supported ingestion framework. Direct table writes can bypass protections that prevent duplicate or conflicting CIs. If a product’s data model is unusual, model the transformation explicitly instead of hiding assumptions inside a script with no operational documentation. Official Discovery and manual onboarding choices offer useful alternatives when an API feed is not the right first source.
Separate collection, transformation and identification
Think about three failures independently. Collection fails when a token expires or API pagination drops records. Transformation fails when a hostname maps to the wrong attribute or a cloud region is flattened into a free-text label. Identification fails when the transformed identifiers do not match the intended CI class rules. Treating all three as “the connector failed” sends operators to the wrong control and encourages repeated imports that multiply damage.
In a controlled test, capture the source record, staged or transformed representation and final IRE outcome. Check the selected class, normalized values and stable identifiers. If a Windows computer is being imported as a server solely because its source product calls it a “machine,” refine the mapping. CI Class Manager classification rules establish why class semantics govern more than a report filter. Repeat with a second source to ensure the design is not tuned for the first payload alone.
Let IRE decide which CI the payload represents
The Identification and Reconciliation Engine (IRE) is responsible for identifying an existing CI or determining that a new one is appropriate, then enforcing source-specific attribute precedence. Identification needs stable evidence, not simply a display name. Reconciliation needs explicit authority: the security scanner should not overwrite lifecycle owner information merely because it ran more recently. Both steps should be testable with known existing and genuinely new items.
Create test cases with one source alone, the same CI from two sources, a renamed host and two distinct devices with similar names. An incorrect match is as damaging as a duplicate because unrelated assets can have their attributes or incident history blended. Use Identification and reconciliation principles to interpret the IRE outcome. Do not “fix” collisions by disabling checks or broadening matching criteria until every record becomes indistinguishable.
Design multi-source authority at the field level
Source precedence can vary by attribute. The cloud inventory may own provider instance ID and subscription, while the endpoint service owns patch version, and a governed human process owns a business-critical support group. Document those divisions with a reason for each. If two sources both claim to own the same field, the reconciliation decision is a governance question, not an arbitrary technical default.
Also plan the moment an authoritative source goes away. Losing a feed should not automatically erase trusted CI data or leave stale values masquerading as current facts indefinitely. Monitor source freshness and set review thresholds. Where the platform exposes source details through CMDB 360, compare observed values and provenance before changing priority. The value of multisource support is explaining which value is current and why, not merely storing all values in one record.
Ingest relationships as carefully as attributes
A server with accurate serial and operating-system values can still be operationally misleading if its application dependencies are missing. Determine whether the integration has evidence for a relationship, its type, direction and relevant endpoints. A discovered network connection is not automatically a business-service dependency. The transformations that create relationships need source provenance and validation just as CI attributes do.
For the retailer, suppose a load balancer appears in one feed and a web application in another. The integration team should confirm that their relationship expresses the deployed architecture, not assume every nearby node is a dependency. Test the result in Unified Map and in a scoped relationship query. If an updated connector suddenly creates a dense web of improbable links, roll back the mapping before reporting a new and misleading service-impact view.
Make onboarding observable before the first full load
A production connector needs more than a schedule. Record successful and failed collection runs, transformation rejects, IRE operations, duplicate trends, and the age of the last trustworthy update. Use the supported integration and workspace monitoring views relevant to the installed application and release; do not assume that one screen contains every custom integration. Establish who receives errors and the criteria for retry versus quarantine.
Start with a sample of known assets, then expand by class or source segment. Compare unique CI counts and representative attribute provenance after every expansion. A surprisingly high insert count may indicate broken identification; a suspiciously low count may mean two devices were merged. The Data Foundations dashboards show downstream quality signals, but ingestion metrics are necessary to diagnose causes before the damage appears as a health score.
Handle replay without duplicating business records
External APIs time out, jobs restart and source batches arrive out of order. Design the integration so a repeated payload can identify the same CI rather than create another record. Store enough run context to distinguish a retry of the same version from a genuine new observation. Respect IRE behavior and source identity fields instead of relying on “last import wins.” Where incremental synchronization is supported, define how deletions and lifecycle transitions will be expressed safely.
A practical failure drill stops the connector halfway through a batch. After restarting, verify whether previously ingested records are updated rather than reinserted, and whether incomplete relationships are repaired. Do not delete a population and reload it as a routine recovery technique; incidents and change records may refer to the existing CI identifiers. Duplicate remediation is for controlled cleanup when prevention has already failed, not a substitute for idempotent ingestion.
Secure the connection without making it unmaintainable
Connector credentials and permissions should be sufficient for the data being collected, not broad administrative access to unrelated systems. Use the source provider’s supported authentication pattern, controlled credential storage, and regular rotation. Restrict who can change mappings, schedules and reconciliation authority because an integration misconfiguration can be a security and operational integrity incident. Log changes without exposing secrets or unnecessary personal information.
Source ownership matters when the integration team and CMDB team are different groups. Agree who renews access, who investigates missing assets, and who approves newly collected fields that could contain sensitive data. Onboarding more attributes is not always beneficial. Every new field introduces transformation, storage, access and retention decisions. A controlled pilot gives security and data stewards an opportunity to reject fields the CMDB does not need.
Version a connector as part of the data model
A connector or ETL transform update can change class mappings, field types, identifier priorities and relationship creation. Record the previous settings and sample payload outputs before a release. Test representative older and new devices, boundary values, unexpected nulls and source conflicts in a nonproduction environment. Where a source adds a new device class, review the CMDB hierarchy and authority rules rather than silently placing it into a generic bucket.
During deployment, monitor both immediate job completion and the downstream change in CMDB health. A drop in orphan records might be genuine cleanup, or a sign that two identities are being merged incorrectly. A post-release review should include business-impact examples, not only green connector dashboards. The CMDB Workspace stewardship workflow helps assign ownership when change causes conflicting CIs or reference issues.
Diagnose one difficult ingestion case end to end
Suppose two device inventories disagree about a virtual machine’s hostname and patch state. First establish whether the provider instance identifier or another stable key proves they describe one asset. Next inspect the intended CI class and transformation, then the IRE identification result. If there is one CI but patch state comes from the older inventory, the likely problem is attribute authority or freshness, not identification. If there are two CIs, investigate mapping and identifiers before reconciliation order.
Finally inspect relationships, update timestamps and the effect on operational queries. Write a small regression test using both original payloads and one intentionally similar but distinct device. A successful fix should preserve one correct CI identity, maintain source provenance, and allow the next normal scheduled run without manual cleanup. That is what “integration complete” should mean to both a ServiceNow implementer and the teams depending on the CMDB.
Diagnose the failing stage in an ingestion pipeline
The exam may describe accurate source data producing duplicates, a connector completing while health scores worsen, or an attribute being overwritten by a less trusted feed. Identify the stage: data collection, transformation/class selection, IRE identity, attribute reconciliation, relationship ingestion, or monitoring and governance. Choose a control that addresses that stage. Re-running a connector is rarely the right answer when its mapping or authority rules are still wrong.
For hands-on preparation, onboard a small authorized data set with two intentionally overlapping records. Document the source contract, mapping, identifiers, expected IRE result, authoritative fields and validation query. Run it, introduce one controlled conflict and trace what changed. You will learn more about reliable CMDB ingestion from that evidence than from memorizing the names of integration products without understanding how they interact.