A CMDB integration is successful only when it preserves the meaning of the data after the first load. Thousands of imported rows mean little if the next run creates duplicate servers, an endpoint feed overwrites an application owner’s decisions, or a financial asset record is mistaken for a live configuration item. In ServiceNow CIS-DF, ingestion scenarios ask an implementer to select an appropriate source, preserve stable identities and relationships, and maintain upgradeable platform behavior. That requires more than understanding how a CSV file becomes records in ServiceNow import sets.
Begin with the intended CI and the question it must answer
Before choosing an integration method, define the target object. A physical laptop, a virtual machine, a logical database, an application service, and a business capability have different identities and refresh needs. Determine its appropriate CI class, stable identifiers, operational attributes, relationships, and who can validate the result. The importer should preserve those semantics. An external inventory product may call an object “asset” even when ServiceNow should represent it as a CI; a finance system may contain an asset purchase that never became an active deployed configuration item.
Use a simple source contract: the external system and its permissions; which objects it reports; its authoritative identifiers; how it distinguishes tenants, accounts, locations, and environments; field-level source ownership; expected refresh cadence; relationships and dependencies; error handling; and when records should be retired. The contract should also record what the source cannot reliably provide. A scanner that cannot see a managed service does not justify inventing a CI solely because the business application needs a dependency map.
This work connects directly to the CIS-DF exam: the Ingest domain covers ingestion method, automation opportunities, manual/non-discoverable CIs, relationship population, security/compliance identifiers, upgradeability, and asset–CI alignment. Rather than memorize a list of available connectors, learn the tradeoffs that decide which method is appropriate.
Choose Discovery when observation of the environment is the right source
ServiceNow Discovery is useful when infrastructure can be observed through supported credentials, network access, and the relevant patterns. It can discover devices, operating systems, installed software, and relationships depending on the configured scope and capability. Its evidence comes from observing a system, not from assuming a planning spreadsheet is true. Discovery schedules, credential failures, changing network boundaries, and mis-scoped patterns can explain why a CI becomes stale or incomplete.
An example is a set of on-premises application servers. If the required network access exists and the instance supports the class, automated discovery can provide repeatable observations of hosts and runtime attributes. A responsible design tests identity rules, account boundaries, credential handling, and expected dependency results against a sample first. It also considers whether a host’s actual business service association requires input from application owners rather than being inferred from the presence of a process alone.
Discovery is less convincing when the source of truth is an external SaaS control plane or an endpoint-management service that already knows the supported object identity. The fact that a record can be created through a scan does not mean scanning is the cheapest, most accurate, or most maintainable source. The best method depends on where the underlying truth can be observed and how the integration will be operated.
Use Service Graph Connectors and IntegrationHub ETL for supported external feeds
A Service Graph Connector provides an integration path for specific third-party systems and can combine source data with transformations designed for ServiceNow CMDB classes. The platform documentation describes IntegrationHub ETL and the Robust Transform Engine as means of mapping data before it is handled through the Identification and Reconciliation Engine (IRE). This architecture helps normalize class meaning and preserve identity when multiple external feeds represent overlapping infrastructure.
For instance, a cloud account feed may report a stable resource ID, subscription or account, region, tags, and lifecycle state. An endpoint-management connector may report serial numbers, assigned users, installed agents, and device compliance. If both describe the same device, the design should coordinate identification and attribute authority rather than create two equally plausible CIs. ServiceNow maintains an evolving set of supported connectors; consult the current Service Graph Connector reference instead of assuming every named application has a built-in connector at the same capability level.
The mapping itself needs governance. A source field called Owner may identify a cloud-account billing contact rather than the production application’s support group. Blindly populating the CMDB owner with that value is a semantic error despite a successful ETL job. Describe each mapping’s business meaning, transformation, fallback behavior, and owner. Prefer supported transformation and connector mechanisms to undocumented modifications of core fields; customization that seems expedient at deployment can become expensive at the next upgrade.
Use import sets or governed manual records when the source warrants them
Import sets can stage external rows before transform maps populate target records. They are suitable for controlled migrations, certain custom feeds, and data flows whose transformations are understood and supported. The existence of a transform map does not prove that the correct CI was matched; validate how the target class, identifier fields, and IRE workflow interact. Unrestricted direct writes to cmdb_ci or a custom script inserting CIs without stable identity logic create future reconciliation and deduplication problems. A repeated import should have idempotent behavior: running it again with unchanged source data should not create new copies of the same objects.
Some objects are non-discoverable by design, not because an operator forgot to configure a probe. A vendor-provided SaaS capability, a governed business application, a planned technology service, or a compliance reference may need human stewardship. Create these through appropriate supported mechanisms with a named owner, status, identifier, and review cadence. Do not assign false technical characteristics or “last discovered” evidence to make a manual CI look automated. A scheduled attestation may be more appropriate than a recurring technical discovery attempt.
Manual records should still comply with CI identification and reconciliation principles. A logical service object needs a stable identity and a documented relation to the deployed components that support it. The governance difference is in how the data is validated, not whether the record deserves quality controls.
Populate relationships with the same care as attributes
A CI list alone cannot answer impact questions. Real relationships can come from Discovery, Service Mapping, connectors, supported inference, or deliberate manual stewardship. Choose relationship types that express an actual dependency and maintain correct parent/child semantics. If two integrations each assert different topologies, inspect which view is reliable and relevant to the application rather than unioning every edge into a noisy map.
A network device’s neighbor information may not establish the application-service dependency that an incident manager needs. Conversely, a manually associated business service offering should not be treated as a technical network link. Work with the CSDM service and relationship model so referential, portfolio, deployed, and consumer-facing relationships are assigned correctly. Record which tool can maintain each relation and how the ownership team will spot drift when infrastructure changes.
If an incoming feed contains relationships, check whether the endpoints were correctly identified and whether relationship creation is supported for the chosen class pair. A relationship that points to an obsolete duplicate CI can mislead impact analysis even when both endpoint records have all required fields. The operational test is whether a known incident can trace a failed component to the real affected service.
Keep asset lifecycle separate from configuration lifecycle
An asset often represents an object for procurement, financial tracking, warranties, custody, and disposal. A configuration item represents a managed component and its technical or service relationships. Physical items can have both an asset record and a CI record, but the relationships between them need valid identity alignment. A laptop may be purchased, stored, allocated, placed in service, repaired, and recycled; its configuration state can change independently from the purchase ledger. A cloud server may exist as a CI without matching a traditional physical asset purchase.
Avoid equating “asset assigned to a user” with “CI actively discovered” or assuming one lifecycle always updates the other automatically. Where ServiceNow supports lifecycle mappings, validate which statuses and objects participate. A purchasing system might declare a server disposed of while a discovery source still observes it—an important discrepancy requiring investigation rather than an automatic deletion of the CI. Similarly, a decommissioned server can retain historical incident and change references after its active use ends.
Security and regulatory identifiers add another modeling problem. A regulated business service might require identifiers linking requirements to business applications, services, or other CSDM entities, not a free-text compliance field copied onto every host. Identify the data owner, correct target object, relationship, and evidence refresh. Security classification is not useful when nobody can explain which system or business obligation it describes.
Trace errors through source, transform, IRE and downstream use
A good integration runbook follows errors through stages. Did the source report the object? Did authentication or scheduling fail? Was the payload transformed to the right class and field formats? Did IRE match the intended CI? Was an attribute update rejected by source precedence? Were needed relationships created? Did dashboard evaluations reflect the new records? The same symptom, such as “stale CI,” can arise at several of these layers, each requiring a different repair.
For a controlled test, ingest a small sample of cloud resources twice and compare record identities. Deliberately include one renamed display name and one missing identifier to see how behavior changes. Reconcile a source disagreement over a single noncritical attribute. Verify the resulting CI count, source history, and relationship endpoints. Repeat after adjusting the mapping, and document whether the fix prevented new duplicates. Do not test risky bulk deletion or alter production identification rules solely for an exam lab.
In production, require monitoring of failed or delayed source jobs, change control over mappings, credentials with the necessary least privileges, and clear escalation when the source’s schema changes. Measure useful outcomes such as duplicate rate, refresh reliability for principal classes, and coverage of validated service dependencies. A fast import that destroys confidence in the CMDB is not a successful ingestion design. For CIS-DF, the right answer pairs a fit-for-purpose source with stable CI identity and maintainable operational governance.