ServiceNow Common Service Data Model Integration Patterns

Integration patterns for the Common Service Data Model determine how services, applications and infrastructure get into the model and how other modules read them back. This page covers inbound population from discovery, cloud platforms and orchestrated manual entry, outbound use by incident, change and asset management, hybrid patterns for services and workloads, Integration Hub and orchestration, metadata enrichment, validation and consistency, and error handling and ownership. The later sections settle which source owns each attribute and the build order for an inbound feed.

Inbound Integration to CSDM: Data Population

CSDM must be populated with data: services, applications, and infrastructure. Integration patterns for inbound data include: discovery (automated probing of infrastructure), cloud platform integrations (fetching AWS, Azure, GCP resources), and manual entry with orchestration assistance (submitting service definitions via automated workflows).

A typical inbound pattern: Discovery scans infrastructure and populates CSDM with servers, databases, and networks. Cloud integrations pull cloud resources and represent them as CSDM CIs. Applications are either discovered (if they publish metadata) or manually entered. Once populated, the CMDB records that CSDM defines become the source of truth for infrastructure topology.

Outbound Integration from CSDM: Using CSDM Data

Once CSDM is populated, modules use CSDM data for their own purposes. Incident Management uses CSDM relationships to determine impact when an incident occurs. Change Management uses CSDM to assess risk: how many CIs will be affected by this change. Asset Management uses CSDM to track asset lifecycle. Integrations flow outbound from CSDM to these modules, keeping them aligned.

Outbound patterns include: change management queries CSDM to show affected services when a change is created, incident management queries CSDM to show impacted applications when an incident is assigned to an affected CI, and reporting modules query CSDM to generate infrastructure and service reports.

Hybrid Patterns: Services and Workloads

Modern applications often have multiple deployment models: on-premises infrastructure, cloud platforms, containers in Kubernetes, and hybrid combinations. CSDM integration patterns must handle this complexity: representing a service that spans on-premises databases, cloud middleware, and containerized APIs.

Hybrid patterns involve: Discovery for on-premises infrastructure, cloud integrations for cloud workloads, container integrations (Kubernetes, Docker registries) for containerized workloads, and orchestration to link them into a logical service. The result is a unified CSDM view of a service spanning multiple technology stacks.

Integration Hub and Orchestration for CSDM

Integration Hub and Orchestration are often used to populate CSDM and keep it synchronized with external sources. A pattern might be: when a cloud platform alert indicates a new resource, an orchestration creates a corresponding CMDB record in CSDM. When a change is requested, orchestration updates related infrastructure records in CSDM. These patterns ensure CSDM stays current as infrastructure changes.

Metadata Enrichment and Context

CSDM tracks infrastructure, but operational context is equally important: which services are critical, who owns each service, what compliance controls apply? Integration patterns include: pulling ownership and context data from HR systems (who owns service X), pulling compliance metadata from compliance management systems, and enriching CSDM records with business context during integration.

A complete CSDM includes both infrastructure topology (which servers run which applications) and business context (which business units depend on which services, what is the criticality level). Integration patterns must account for both.

Validation and Consistency Patterns

When multiple sources feed into CSDM (Discovery, cloud integrations, manual entry), data can diverge: CSDM shows a server in one place, cloud platform shows it in another; CSDM shows a dependency that no longer exists. Integration patterns should include validation: periodic reconciliation between CSDM and external sources, identification of inconsistencies, and correction workflows.

A validation pattern might be: monthly, run a reconciliation job that compares CSDM infrastructure counts to cloud platform counts and flags discrepancies. Discrepancies are reviewed by a team who either updates CSDM or corrects the external source.

Error Handling and Integration Ownership

Integration patterns must handle failures gracefully. When a discovery scan fails, or a cloud API is temporarily unavailable, the integration should retry or queue the work rather than leaving CSDM with stale data. Error handling patterns include: retry logic with exponential backoff, dead-letter queues for failed messages, and alerting when integrations fail repeatedly.

Integration ownership is equally critical. Who is responsible for troubleshooting when CSDM data is incorrect? Who maintains the integration code and handles cloud platform API changes? Define clear ownership: typically, the CSDM administrator owns the data quality, integration engineers own the integration code, and cloud platform teams own handling their API changes. Regular communication between teams prevents finger-pointing when issues occur.

Deciding Which Source Owns Each Attribute

A CSDM integration works only when every attribute has one source that is allowed to change it. Without this step, a configuration item can end up with a name from a scan, whose owner comes from a spreadsheet, and whose operating status comes from a monitoring tool that polls on its own timer. Each source is correct on its own terms, and the record is still wrong, because the last sync to arrive wins. Before any connector is built, write a table that lists each attribute the model depends on, the source that is authoritative for it, and what the platform should do when a second source disagrees.

The matching key deserves more attention than the field values. A name is a poor key because it changes during renames and collides across environments. Use a stable identifier where one exists, and where none does, define a composite key from fields that do not change together, such as the class, the host identifier, and the environment. The identification and reconciliation logic in the platform will only be as accurate as the keys it receives.

Build Order for an Inbound CSDM Feed

1. Decide the scope in plain terms: which classes and which attributes this feed may write. Anything outside that list is out of scope and should be rejected at the boundary, not silently ignored.
2. Agree the matching key with the source owner, and test it on a set of records that include known duplicates.
3. Build a dry-run mode that logs what would be created, updated, and skipped, and review a full run before any writes are enabled.
4. Enable writes for creates first, then updates, then deletes. Deletes are the riskiest operation and should wait until the first two have been stable for a full cycle.
5. Define what a missing record means. A record that disappears from a source may have been retired, or the source may have failed to report it. Only treat absence as retirement after a confirmed successful run.
6. Monitor the feed for volume changes. A sudden drop in records received is often a broken connector rather than a real infrastructure change.

Failure Patterns That Hide in the Data

A damaging pattern is the tombstone that never arrives. A server is decommissioned, the scan no longer sees it, and the feed never tells the model it is gone. The record stays, its relationships stay, and impact analysis keeps reporting a service that no longer runs on it. The remedy is a deliberate retirement path, driven by confirmed absence, rather than trusting that deletion will propagate on its own.

A second pattern is the duplicate that appears only in one environment. Test and production hosts can share a hostname, and a key that omits the environment will merge them. The records look plausible in isolation and only reveal the problem when a change to one environment appears under services that run in the other. Include the environment in every key that is used for infrastructure.

The third pattern is the silent override. An automated feed writes a field that a human had corrected by hand, and the correction disappears at the next run. Protect manually maintained fields by excluding them from the feed’s write list, and make the exclusion visible in the mapping document so that the next engineer does not remove it by accident. The security and access design for CSDM is where to check who may maintain those fields.

Cases where a feed should only propose changes

Some relationships should not be written by any automated feed. The link between a business service and a customer-facing dependency is a decision, not a fact that a scanner can observe, and writing it automatically turns a judgment into a record nobody reviewed. In those cases the integration should create a proposal for the owner to accept, not a finished relationship. The same reasoning applies to any feed that would change which services a piece of infrastructure is attached to.

Frequently Asked Questions About CSDM Integration Design

Should the CSDM feed be push or pull?

Choose by who controls the timing. The data source governance post covers how each source is approved before it writes anything. Pull suits a source you can query on a schedule and whose data changes slowly. Push suits a source that emits events when something changes, such as a deployment tool. Many estates need both, and the design should say which attributes come from each so that two paths do not write the same field.

How often should reconciliation run against an external source?

Run it on a cadence the team can act on. Reconciliation that runs more often than anyone reviews its output can just generate noise. Start with a schedule that matches the review cycle of the people who fix discrepancies, and adjust it once you see how many items each run produces.

What should the integration log record?

For each run, record the source, the time, the number of records received, created, updated, skipped, and rejected, and the reason for each rejection. Those counts are a quick way to tell whether a feed has changed behavior, and they become the evidence an auditor asks for.

Who should be on call when a CSDM feed fails?

The integration engineer for the connector, with the CSDM administrator informed because data quality is their concern. A failure that leaves the model stale without an alert can be more dangerous than a loud one, so route feed failures to a monitored queue rather than an email box that few people read.

Next Step for Your CSDM Integration Design

A useful input is the list of attributes each source currently changes, since that is where conflicts often start. The integration error handling post covers the failure side of the same design.

CSDM integration patterns: tables, fields and values to name in the design

A Common Service Data Model feed works when every record is written through identification and reconciliation, not inserted straight into a table. Name the target class for each source, the attribute each source owns, and the relationship that ties a service to its infrastructure. A feed with those three decisions written down is far easier to support.

These are common out-of-box names. Check them on your own instance and release, because class labels and defaults change between releases.

Two rules keep these feeds clean. First, send CI data through the Identification and Reconciliation Engine, so duplicates are matched against identification rules and reconciliation rules decide which source wins a conflict. Second, stage external data first and transform it second, so a bad source file is caught in staging before it reaches the CMDB.

Example (hypothetical): an application portfolio tool exports a list of business applications with an owner name. The team stages the export in an import set, maps the owner to a user reference, and writes business application records. A separate, narrower feed then links each application to its application service. If either feed fails, the other still runs. The Common Service Data Model overview shows how these layers fit.

Which feed should create service offerings?

Usually none. Service offerings describe commitments, so they are normally created by the service owner or a controlled catalogue process. A feed can read them, but letting an external source create them tends to produce offerings nobody supports.

Should relationships come from the same feed as the records?

Prefer separate steps. Load the records first, confirm they reconciled, then write the links in cmdb_rel_ci. A relationship written before its parent exists can fail or point at a duplicate, and the error is harder to trace.

How do discovery and a custom feed avoid overwriting each other?

Set reconciliation rules so that Discovery owns technical attributes and the custom feed owns business attributes. The reconciliation and duplicate control approach explains how to record that choice.