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.
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).
