Using Data Service Instances to represent System Integrations: A Good Idea?

[Bruno De Graeve]

When managing integrations between systems or services, one recurring question is:
Where should we store integration information in ServiceNow?

In this discussion, we focus on the operational aspects of integrations, as opposed to the design aspects typically addressed by Digital Integration Management within the Enterprise Architecture application. Our goal is to make integration data actionable and usable in ITIL processes, not just documented for architectural design.

With CSDM v5, the Data Service Instance class was introduced as part of the Common Service Data Model. This opens up an opportunity to use it for representing and tracking system integrations in a way that supports operational workflows.

Why Use Data Service Instances for Integrations?

This approach allows you to:

• Describe the data flow between systems.
• Define dependencies with other Configuration Items (CIs).
• Add metadata and establish “Depends On” relationships (e.g., to middleware handling data transport).

Think of this as an instantiation of the Digital Integration concept from Enterprise Architecture—similar to how a Business Application is instantiated by one or more Application Service Instances. The difference is that here we are focusing on operational visibility rather than architectural design.

How Could This Look in Practice?

• Use CI Class "Data Service Instance" [cmdb_ci_data_service_instance] made available by the CMDB CI Class Models app.
• Use a specific Product Model to indicate that the CI represents a System Integration.
  I propose to use a Product Model representing a System Integration, leveraging the out-of-the-box Model ID to avoid relying on changes in the the Service Classification choice list. Taking this, you can easily find your integrations back, as there might different types of Data Service Instances. The System Integration type product model also allows you to describe an integration pattern, that can indicates which components make up the data service (f.i. an integration making use of MID server, or gateway/ETL solutions like Mulesoft, Boomi, SAP Cloud Integration).
• Leverage the Exchange data with CI relationship to model the data exchange.
• Dedicated form that captures the minimal integration details:
  
  

Based on the description of a Data Service Instance (see list of classes ) : "A Data Service Instance extends a Service Instance and represents a logical instance of a data service that can persist structured and unstructured data, process data (pipeline) or retrieve data (data, search, query, etc.)."; I believe it covers well a System Integration.

Once modelled, an integration service could appear as a distinct CI in the CMDB, linked to the relevant Service Instances, which are instantiations of Business Applications. In the example we modeled an integration between Active Directory and the ServiceNow Platform, in the Prod environment. It logically represents the data influx of new and updated employee data, managed in the corporate Identity & Access Mngt system, into the Now platform; to be used as agents and allow employees to interact with the platform.

(Note: I’m still exploring how to best visualise downstream relationships in the Unified Map.)

 

Why This Matters ?

• Avoid outdated sources: Customers often store integration details in wikis, spreadsheets, presentations, or other disconnected sources that quickly become outdated.
• Enable dependency mapping: If integration data is stored outside the CMDB, it cannot be used for dependency mapping or impact analysis.
• Support ITIL processes: Integration details become actionable for Incident, Change, and Problem Management. This is particularly useful when troubleshooting issues involving integrations.
• Leverage Service Graph Connector (SGC) for MuleSoft: ServiceNow provides an option to import MuleSoft "applications"; which are essentially integrations between systems; into the CMDB. Customers want to select these integrations on incidents and changes, and this SGC uses the Data Service Instance class to store these "applications" (aka integrations).
• Use our Platform ! The retrieved data might even be used in one or the other AI use case.

Please share your feedback. I can imagine there might be feedback how to model the CI relations between the Service Instances (aka Application Services) and the Data Service Instance.

Disclaimer:

As in our safe harbour statements, we tell our customers not to make any buying or implementation decisions based on this info. As this functionality is build around new data entities which will be in time used by the business units; similar of what is highlighted in the in the latest CSDM Fundamentals training, we caution you that future functionality may conflict.

Addendum:

To be able to create a new Data Service Instance, apply attached update set(s) (one contains the configuration, the other the demo data used above). The missing New button, is a known issue tracked as PRB1865417. As a workaround, you can create a custom UI Action and ACL for the cmdb_ci_data_service_instance table. You should pattern these after the out-of-box ACL and UI Action for the Dynamic CI Group table (cmdb_ci_query_based_service).

[Lisboa]

This is rather insightful.  It helps take some of the intangible aspects of IT and makes them much more operational.  Find it a very good touch (good/best practice) that the naming convention applied in the example uses arrows to indicate Source/Destination (or bi-directional). Doubt it was intentional, but that alone provides tremendous value for someone trying to understand "the flow" of the integration.

This was awesome!  Thanks for pursuing this!

[Bruno De Graeve]

@Lisboa thanks for the great feedback. Hopefully the arrow renders everywhere as it should 😉 I'm glad to see it a small visual thingy that provides value. Let the feedback come so that we can try to establish a working standard that we all can apply.

[Lisboa]

Punchline for me is that it helps operationalize some of the more ethereal/code components in IT.  When integrations fail, often times people point to an application when the issue may be directly in the translation table (typically the result of a change) or something less-than-direct than slapping an incident onto the application itself.

[Lisboa]

We are moving forward with this in our lower test environments at present.  Will report back on how it goes from a roll-out and adoption perspective.  The plan at the moment is to use it to create all our ServiceNow related integrations as a PoC.

I'm genuinely curious on specifying the directionality of the integration.  Part of me likes:

• Feeds: Fed By  (for mono-directional)
• Exchanges with:Exchanges with (for bi-directional)

Going down the rabbit hole on some thoughts here, specific to ServiceNow and ticketing flows:

• How does one apply Data Service Instances leveraging a Service Bridge Integration?
• For ticket integrations, do you specify integration by ticket type (Incident Integration, Request Integration, etc.)
  • Do you go so far as to specify integration by phase/stage (On New, On Update, On Resolve, On Close, On Cancel)?
• How do you "complete" an integration when the source or target system CI is outside your organization's purview/network?  (Integrating with customer or service provider provisioned system.)

I get the notion of keep it simple/start simple and build to complexity - just the mind wandering here.

[Bruno De Graeve]

@Lisboa Thanks for sharing your latest feedback and before I forget, I wish you and the other community members a healthy 2026 !
I like the idea of using different CI rel types which even could be controlled, when you use Enterprise Architecture/Digital Integration Management. I see the Data Service Instance as an instantiation of a Digital Integration; although it's not defined yet how exactly they will be related (a reference or m2m). If you have EA, I would document some of the aspects you mentioned on the Digital Integration, as you might have multiple environment-specific instantiations for one digital integration. F.i. the type of integrations can be documented using the Type and Subtype fields (which can be enhanced with yr values).

 
Digital Integration Management also solves the challenge where you need to document an integration with an external company. In that cases, you document a Digital Interface and link to a Company instead of a Business Application.
Digital Interfaces can be instantiated as APIs (table = cmdb_ci_api), which has a reference to a Company.

Could be maybe mapped or conceived as:
Company <- API <-> Data Service <-> Service Instance (aka Application Service) -> Business Application 

let me know if you have further questions. Nice discussion !

regards, bruno

[ahbrook]

Hey @Bruno De Graeve ! 

I'm curious - have you made any more progress or insights on this in the last year? I'm especially curious about upkeep and management. 

We are currently doing an audit of our integrations. Without even doing too much digging, we've found about 300 unique integrations that happen in our production environments. Many of these are SFTP file transfers that utilize specific data objects/types, but there are just as many that use custom developed ETL tools in between. Further, many of these are moving sensitive data.

We currently only have access to ServiceNow ITSM and SPM, so I know I can't leverage the Enterprise Architecture data integration elements. We also can't use Discovery to auto-classify communications between systems. But I'd like to set up for a future where we might have that as a possibility.

Do you see value in creating separate product models for each kind of query or transport mechanism we use, or just leaving that for the notes section to fill in? 

[Bruno De Graeve]

hello @ahbrook 

Thanks for the follow-up, and for sharing the context. I’ll come back with a fuller update on our progress, but here are some thoughts in the meantime.

It’s encouraging to see more organisations paying close attention to what flows in and out of their platforms. Your audit result (around 300 integrations, many carrying sensitive data) is typical, and it shows why a wiki page or spreadsheet doesn’t hold up. What you’re describing is essentially a lightweight Digital Integration Management (DIM) approach, managed within the CMDB. I still believe the approach in the article holds, and it fits well with ITSM-only licensing. The Data Service Instance class (cmdb_ci_data_service_instance) is part of the CSDM 5 Service Delivery domain, with a Service Classification of Technical Service. That means it behaves like any other operational CI: you can select it on incidents and changes and use it in impact analysis.

On product models versus notes

I’d model it rather than rely on the notes field. Notes are free text. They can’t be reported on reliably, they aren’t enforced, and after 300 records you’ll have 300 different ways of writing “SFTP”. A product model (cmdb_model, which is reference data and not a CI) gives you a controlled value to group, filter, and report on. It also lets you describe the integration pattern once, centrally, instead of on every record.

The key is granularity: model the pattern, not the variant. If you have 20 SFTP transfers that differ only by host, schedule, or file format, that’s one product model. The variations belong in attributes on the CI. A useful rule of thumb: create a separate model only when integrations are supported, monitored, or risk-assessed differently. If you’d never filter a report on the distinction, it’s an attribute, not a model. For your landscape, a starting set could look like this:

• File transfer – SFTP (point to point)
• File transfer – via managed file transfer platform
• API – direct REST/SOAP
• API – via API gateway
• ETL – custom developed
• ETL/iPaaS – commercial platform (e.g. MuleSoft, Boomi)
• Messaging/event streaming (e.g. Kafka, message queues)

That’s typically enough to answer the questions people ask, such as “how many of our integrations still rely on custom ETL?” or “which file transfers move data outside a managed platform?”

On upkeep and management

This is where most initiatives fail, so a few practical points:

• Ownership. Give every integration CI an owner and a support group. An integration without an owner will go stale.
• Lifecycle. Use the CSDM life cycle stage and status fields so retired integrations are marked as such rather than deleted or left behind.
• Hook into existing processes. With ITSM and SPM, you already have the entry points. Make registering the integration CI a step in your demand or project intake, and require a change against that CI when an integration is modified or decommissioned. If the record has to exist for the process to continue, it stays current.
• Periodic review. Schedule a recurring review where owners confirm their integrations are still accurate, starting with the ones carrying sensitive data.

With 300 integrations, I wouldn’t try to load everything at once. Start with integrations moving sensitive data and those supporting your most critical services, then expand.

On future-proofing

This model gives you a solid landing zone. If you later license Enterprise Architecture, the DIM digital integration becomes the design-level record, and your Data Service Instances are its operational instantiation, similar to how a Business Application is instantiated by Application Services. Discovery won’t create these logical integration records for you, but the infrastructure and connection data it brings can later be related to them. And if you use MuleSoft, the Service Graph Connector for MuleSoft already populates the Data Service Instance class, which confirms this is the right class to build on.

On sensitive data

Since many of your integrations move sensitive data, look at the Information Object class (cmdb_ci_information_object). CSDM 5 positions it to identify the types of data an application holds, such as PII or PCI. Relating your integration CIs to Information Objects lets you report on “all integrations carrying PII” instead of relying on someone’s memory. This also aligns with where Enterprise Architecture goes: DIM in EA links digital integrations to information objects too, so the work you do now carries over.

It’s also worth reading the two guides @Kristine Naess  published on information objects and regulatory requirements:

• CSDM 5 Information Management Implementation Guide v1.0, co-authored with Rob Koeten. It covers information governance, data lineage, and compliance automation, including how to map information flows across systems for regulatory proof points and track data lineage for impact analysis and incident response. That’s very close to what you’re trying to achieve with your integration audit.
• DORA CSDM 5 Implementation Guide, which explains how to use the CSDM for better, more automated DORA ITS reporting. Even if DORA doesn’t apply to you, it’s a good example of how CMDB data becomes regulatory evidence.

[TrishP]

Brillian artile @Bruno De Graeve !

Very timely for our organization as having a centralized, visible and integrated repository for these integrations become more and important.  The fact that this data is also available to our AI tools is the icing on the cake.

Thank you!