A CMDB ingestion design is not a contest to import the most rows. A collector can discover a VM and its network interfaces, an asset feed can provide purchase and ownership facts, and a service owner can identify a logical application that has no device to scan.<\/p>\n
Those sources answer different questions. Good ingestion selects the relevant CI class, stable identifier, attribute authority and relationship mechanism before connecting the feed. Otherwise more data can make the CMDB less useful through duplicates or conflicting attributes.<\/p>\n
The official Service Graph Connector<\/a> guidance describes supported connector pipelines that ingest, standardize and reconcile data. It also emphasizes ServiceNow class mapping, IRE and IntegrationHub ETL. Use documented integrations where their coverage matches your source and release, then inspect customizations rather than assuming a connector is universally correct for every vendor or CI type.<\/p>\n A useful fictional case involves 3,000 Windows endpoints, 250 cloud databases and 40 manually governed customer-facing services. Windows discovery may capture devices, a cloud connector may report database resources, but no technical scan can infer the service owner or business impact of every application. Plan separate technical and governance pipelines that converge on stable CI identities.<\/p>\n ServiceNow Discovery collects supported infrastructure configuration data using discovery patterns and credentials appropriate to the environment. It can identify technical dependencies, but there are prerequisites: reachability, collectors, access, patterns, schedule and source-specific limitations. If a system was not discovered, the cause could be visibility or permission rather than nonexistence. Do not interpret a Discovery run with no errors as proof every resource in an organization was scanned.<\/p>\n Service Graph Connectors bring information from supported third-party platforms and cloud services. A connector may pull endpoint inventory from a management product already deployed, making that source preferable to running a new scan. Custom imports or API integrations can be justified when no supported connector meets the requirement, but they need explicit class mapping, transformation testing and IRE-aware processing. These are distinct choices, not interchangeable menu labels.<\/p>\n Import Sets and Transform Maps<\/a> transform incoming records; in ServiceNow CIS-DF<\/a> preparation, the key question is whether each transformed record then follows the intended CMDB identification and reconciliation path. A direct table insert that appears to save configuration time can create costly upgrade and duplicate-management problems.<\/p>\n IntegrationHub ETL helps map source fields and relationships into the target model, allowing administrators to inspect and adjust the transformation path. The mapping must reflect field meaning, not just convenient string matches. A source field labeled `service` might refer to a business offering, operating-system daemon, application deployment or contractual service; mapping all of these to one ServiceNow CI class would distort the model.<\/p>\n Test records with omitted fields, unexpected types and multiple environments. One cloud feed may produce resource identifiers unique only within an account, so identifying an object by short name alone can merge unrelated cloud resources. Relationship mappings need similar rigor: whether a CI is contained by, runs on, or depends on another CI changes service-analysis outcomes. The correct relationship type should be agreed before mass import.<\/p>\n Use small, reversible import batches. After each batch verify the number of new CIs, matched existing CIs, rejected rows, relevant IRE decisions, class mapping and relationship counts. A green connector status shows pipeline activity; it does not prove duplicate-free or semantically correct results. A rollback must specify whether to stop the feed, revert mapping and reconcile already-created records.<\/p>\n Some relationships can be obtained from Discovery, cloud APIs or service mapping. Others require business owners to confirm how a technical application supports a service offering. Do not assume every parent\u2013child link in a schema is a runtime dependency. For example, a server contains a network adapter, a database instance may be hosted by a server and an application service depends on a database. Those links convey different direction and impact.<\/p>\n When a discovered host loses a connection to a database, automated mapping may help update a technical relationship. The relationship between that application service and the business service sold to customers still requires service-modeling governance. Ownership, source, confidence and refresh cadence should be visible for important links; otherwise an out-of-date automated map can mislead change-risk assessment.<\/p>\n CSDM service mapping<\/a> establishes how configuration items support services, while the CSDM 5 service taxonomy<\/a> distinguishes offerings, application-service instances and business application portfolio objects.<\/p>\n Prefer supported interfaces and packaged connector mappings where practical. Unnecessary business rules or direct database writes that duplicate platform behavior may break after an upgrade or bypass identity governance. A customization is justified when it has a documented gap, maintained owner, tests and an upgrade strategy. Avoid hardcoding a temporary UI label as though it were a permanent data contract.<\/p>\n Each integration acceptance record should state source system, connector version, schedule, scope, target class, identifying attributes, reconciliation label, target relationships, expected CI volume and known unsupported object types. Recheck those assumptions when upstream schemas change. A connector can appear healthy after an update while silently reclassifying resources or dropping optional identifiers used by the business.<\/p>\n When a source is retired, plan handoff. CIs should not all become stale merely because a previous collector no longer updates them; the incoming source needs deliberate reconciliation permission. Test before disabling the old feed, preserve provenance history and communicate responsibility for any data gaps.<\/p>\n If one server appears as two CIs, inspect the class and identifiers, then the {link(“ire”,”existing IRE review”)}. If the correct CI exists but its owner flips between two teams after imports, inspect {link(“A3″,”attribute reconciliation”)}. If a business service is absent from impact views, test the service taxonomy, relationships and manual ownership flow before scheduling another infrastructure discovery.<\/p>\n A pragmatic end-to-end ingestion test starts with a source record, captures its transform, follows IRE decisions, inspects resulting CI attributes, checks at least one expected relationship and confirms that a downstream consumer can answer its question. For example, can a change planner find the critical application services on the affected database? That is a more meaningful success criterion than \u201cthe import processed all rows.\u201d<\/p>\n ServiceNow ingestion is a governed pipeline, not a one-time fill operation. Correct class semantics, stable matching, predictable authority, monitored schedules and business-confirmed relationships are what make the collected data durable.<\/p>\n Choose four input records: one new server with complete identifiers, one repeat of the same server, one record missing an important identity field and one dependent component whose parent is unavailable. Define the expected outcome for each before running an integration. The first should create a correctly classified CI, the second should match that CI, and the exceptional records should produce visible decisions rather than silently creating unreliable duplicates.<\/p>\n Add an attribute conflict case with two sources that both report a support group. An acceptance report should show whether the authorized source won, where the rejected evidence can be inspected, and whether the lower-authority source will retry. Include one relationship check: a database instance must be associated with the intended host or service by the correct relationship type, not merely appear in a record list.<\/p>\n Measure the actual CI count and relationships after a small batch and then after a second run. A rising count after identical inputs reveals a problem that a successful HTTP response will not. When discrepancies appear, pause scale-out, preserve payload samples and fix identity or mapping before resuming.<\/p>\n An import can stop providing useful updates without clearly failing. Monitor last successful source execution, record counts by class, new versus matched CIs, identified errors and a sample of critical field freshness. If a schedule unexpectedly returns zero rows, do not instantly retire all previously discovered objects. Investigate source access, filters, network reachability and upstream platform changes.<\/p>\nDistinguish native Discovery from connector and import routes<\/h2>\n
Use IntegrationHub ETL as an observable transformation path<\/h2>\n
Relationships may be automated, inferred, or governed manually<\/h2>\n
Control technical debt and version drift<\/h2>\n
Choose the next diagnostic step from a failed sample<\/h2>\n
Use an ingestion acceptance matrix before scale-out<\/h2>\n
Check integration observability and source freshness<\/h2>\n