Should Application (cmdb_ci_appl) CI's be part of a Dynamic CI group?

[Ravish Shetty]

Hi all,

We are starting our CSDM journey and defining Technology Management Services and Business Services.

As part of CSDM relationship definitions, we are creating Application (cmdb_ci_appl) entries since we don't have ServiceNow Discovery enabled yet, and we are also encompassing them as part of Dynamic CI group and linking those Dynamic CI groups with Technical Service offering and Technology Management Service but we found that the use of Dynamic CI groups is only suggested for Infrastructure CI's as per the CSDM relationships diagram we see below.

Please advise if we should use Dynamic CI groups with Application (cmdb_ci_appl) or not. If we are not supposed to use it with Application, how would we link the Technical Service Offerings with the Application (cmdb_ci_appl) records?

Thanks,

Ravish

[Shubham_Jain]

@Ravish Shetty Nice Question! 

Dynamic CI Groups should NOT be used with Application CIs (cmdb_ci_appl).

Per CSDM best practices, Dynamic CI Groups are intended primarily for Infrastructure CIs, such as servers or network devices — where the membership can vary frequently and needs to be rule-driven.

Why Not Use Dynamic CI Groups for Applications?

• Application CIs are relatively stable, intentional, and uniquely modeled — unlike infrastructure CIs that may scale in/out.
• CSDM emphasizes direct relationships for Application CIs to ensure traceability, accountability, and governance.

How to Link Technical Service Offerings to Applications:-

To model the relationship properly:

1. Create Technical Services (cmdb_ci_service)

• These represent your core technology capabilities.

2. Create Technical Service Offerings (service_offering)

• Offerings under each Technical Service.

3. Link Applications directly using Depends on::Used by

• From the Service Offering, create a Depends on relationship to the Application CI (cmdb_ci_appl).
• You can do this using:
  
• CI Relationship Editor
• Relationship table (cmdb_rel_ci)
• Or populate via Service Mapping / manual association

4. Optionally group Applications using Tags or Application Services

• If you need logical grouping (not dynamic), use Application Services or tags, not dynamic groups.

TIP— If you’re planning to onboard Discovery later — avoid over engineering with dynamic CI groups for Application CIs now. Focus on defining accurate relationships manually or via service mapping logic once Discovery is available.

Recommendation from my end — 

- DO NOT use Dynamic CI Groups for Applications.

- Instead, create explicit relationships from Technical Service Offering → Application (cmdb_ci_appl) using Depends on::Used by.

[mikesisson]

In the relationship map there is not a recommended mapping from Technical Service Offering to Application.  There is only TSO Depends on to Application Service or contains to Dynamic CI, and then for the Application there is only Application Service Depends On Application and Application runs on Infra CI.  Maybe I'm looking at this too black and white?  Is this an exception due to the lack of an Application Service?

[Bobby Campbell]

The only documented examples of a direct relationship between Technical Mgmt Service Offering to Application is using Contains, which is on slide 36 of "CSDM Data Model Examples". In all other cases I can find, there's a Service Instance in between. 

Can you point to reference that shows the depends on::used by relationship between TMSO and Application?  I don't ask as a challenge; rather in hopes there's a document that provides more detail around the correct relationships. Might there ever be an OOTB way to "enforce" only correct relationships?

[Jim Zeigler1]

The Dynamic CI Group class(formerly known as a Technical Service) is a subclass of Application Service. In the ITOM context, Dynamic CI Groups have traditionally been used to group Server and Application CIs that define a shared Infrastructure Service (e.g., a cluster of Database servers and their database CIs).

Dynamic CI Groups are created and updated dynamically by query-based mapping. A table(or DB view) and filter(a query) is created to create a list of CIs that impact the Infrastructure Service(stored as a Dynamic CI group). Dynamic CI Groups are constantly being refreshed by reapplying the filter, so it is a best practice to create the filter so it includes newly added CIs added to the Service.

Query-based mapping can be used to map any Service, especially when Top Down discovery fails to discover all the CIs in a Service. Many of the most complicated Apllication Services depend on  Batch Jobs and other CIs that are not created by discovery.

All Dynamic CI Groups show up in the Operator Workspace Dashboards like regular Application Services and can be included as members of Application Service Groups that define the Application Service Hierarchy.

Dynamic CI groups can also be defined by referencing a CI group containing all the CIs in the group. A CI group can be created using queries.

As I interpret the later CSDM models, A Technical Service Offering can reference a Dynamic CI Group, but this is not used by ITOM because offerings are not operational CIs that need to be monitored.