CSDM Relationships for Dynamic CI Groups

[Carolyn Rast]

CSDM Gurus -

We are in the early stages of building out our services.  We intend to direct the "Owners" and other personas to the Digital Portfolio Manager (DPM).  Currently we do not have Service Mapping implemented.  Our services were initially deployed as tag-based services and are now dynamic CI groups.

Our problem is in the relationships - Technical Service Offering to CIs - DPM is looking for Relationships [cmdb_rel_ci] that don't exist.  Is there any OOTB functionality (other than Service Mapping) which automatically create these relationships? 

We implemented a script to create the missing relationships and are tying it into CSDM Data Sync.  Is there a better answer - something we missed?

[Daniel Borkowi1 · Accepted solution]

Hi @Carolyn Rast , CSDM doesn't includes a direct relationship between Technical Service Offerings. Either there is a relationship to an Application Service or there is a Dynamic CI group grouping Infrastructure CI (Infrastructure Services like Network Services, Server Services). In case of the Application Service there are all Infrastructure CIs related to. 

The relationships beginning from Application Services downwards, can only be populated automatically with Service Mapping OOTB. Other approaches would be manually adding Infra CIs to the Application Service. If you don't want to use Service Mapping or manual approach and maybe have a other source for these informations you can either use a Service Graph connector (if existing) for the source system. This is also able to populate all the relationships. Instead of Service Graph connector you can use IntegrationHub ETL to import the data with populating relationships. 

Other option is, like you did, creating a script. If your CIs maybe have some data which you can use (maybe naming convention) you can automatically create relationships. But I assume that this structure will than be flat and not representing your environment (e.g. representing clusters).

A last approach I have in mind: If you are able to tag CIs (e.g. each CI can be tagged to which Application Service it belongs by populating the table cmdb_key_value) you can use tag based Service Mapping too. With this approach, ServiceNow can populate the relationships between physical CIs like Discovery and pattern based Service Mapping would do (depends on quality and completeness of your data).

Greets
Daniel

Please mark reply as Helpful/Correct, if applicable. Thanks!

[JakubS]

Hi Daniel,

I would have a question related to the scheme you shared - we are trying to relate netgear devices to TSO through dynamic CI groups but there's still a piece that I must be missing. We have the TSOs and the Dynamic groups (and they are populated by a query) created and related, but no relationships are created. Would you what I am missing? Do we need a script or business rule that would actually created the relationships between TSOs and CIs.

Thank you,

Jakub

[Daniel Borkowi1]

Hi @JakubS , thank you for your question! Let me clarify how dynamic CI Groups work in relation to Technical Service Offerings (TSOs).

Dynamic CI Groups are designed to group Configuration Items (CIs) based on a query, but they do not create explicit CMDB relationships (cmdb_rel_ci) between the TSOs and the individual CIs in the group. This is intentional, as creating relationships for every CI in a dynamic group could result in an overwhelming number of relationships, making the relationship diagrams difficult to manage and interpret.

Instead, the connection between TSOs and dynamic CI Groups is handled at a higher level. Processes like Change Management or Incident Management can still interact with the grouped CIs without needing explicit cmdb_rel_ci entries. The system recognizes the relationship between the TSO and the dynamic CI Group, and the query ensures the group is populated with the relevant CIs.

To answer your question directly: you do not need a script or business rule to create relationships between TSOs and individual CIs in the dynamic group. The design of dynamic CI Groups eliminates the need for explicit relationships, as the grouping mechanism itself serves the purpose of linking the CIs to the TSO.

If you need to visualize or work with individual CI relationships explicitly, you would need to manually create those relationships or explore alternative approaches, but this is generally not recommended due to the potential for clutter and performance issues.

I hope this clears up the confusion! Let me know if you have further questions.

Greets

Daniel

[Carolyn Rast]

Thank you @Daniel Borkowi1!

I have come to realize I am missing the Application Service record!  I assumed the Dynamic CI Group WAS/IS the Application Service.  DPM displays the service IFF I build an Application Service as a Manual Service and use the the Dynamic CI Group as the population method.  This construct get past the DPM filter which specifically removes the Dynamic CI Group from the display.