CSDM, Escalation, and Who Supports It (Dynamic CI groups and separation of responsibilities)

[mejasonroar]

CSDM is by far, simultaneously the most confusing thing and yet the most obvious thing. We are trying to implement it at my University and I have trapped myself in a logic hole and am not sure how to get out.

Our plan today is to...

(1) Adding the Service and Service Offering fields to the incident form.

(2) Make the Service field read-only and derived from the offering selection.

(3) Limit the offering field to Business Service Offerings (BSO) only.

(4) Lock the CI field to application services related to the BSO only.

In that setup, a customer calls and the following steps would happen:

1. Help desk tries to help, when they can't, they set the offering and the incident automatically flips the assignment group to the support group associated with the offering.

2. The offering support group tries to work on it, but need to escalate, so they set the CI field to the application service (service instance) providing the BSO. This automatically flips the assignment group to the support group for the application service.

3. The application service group can't fix it, and needs to get infrastructure people involved (tier 3). How the heck does someone escalate to the infrastructure group??

If we modified the offering field to allow selection of BSO *and* TMO, great, but then help desk staff will always choose the wrong thing and continue the cycle of escalating to infrastructure inappropriately.

If we modified the CI field to allow selection of any CI, OK, the app service group could select an infra CI and that would get to infra people, but the app service owners shouldn't know the infrastructure CIs. I don't expect my app owners to know my hypervisors.

I thought maybe dynamic CI groups, but those confuse me. ServiceNow always shows "Windows Servers" as an example, but if I follow that logic, and that TMOs sync their support group to the dynamic CI group, that would imply the group that manages my TMO of Windows Servers is somehow responsible for every single Windows server in my org. In fact, I want my app service owners to manage their servers entirely, including Windows management, and the infra team only manages the infra providing that server. 

That led me down a rabbit hole of thinking about splitting apart dynamic CI groups and having something like "AppX Windows Servers", "AppX Linux Servers", and having *their* support group be set as the app service support group. I think it would work, but then it begs the question, what's the point of having support group set on the CIs AND the app service itself? Is that expected? 

I have been scouring this forum, chatting with AI, and doing general web searches, but am still stuck in this core question: 

How do you escalate an incident from the customer-facing business side (BSO and app service) to the TMSO group who manages the underlying infrastructure WITHOUT exposing all your infrastructure "things" to the entire org for bad assignment?

I'm extremely interested how others are tackling this and if I am missing something. Open to any ideas, even if it means our original plan is blown to bits.

[Matthew_13]

You’re not crazy — this is one of the most common CSDM “logic traps,” and your thinking is actually solid.

The key shift that usually helps is separating context from escalation:

• Service / BSO = what is impacted (customer-facing context)

• Assignment group = who is working it right now

In mature CSDM implementations, infra escalation is not driven by changing the Service or CI. Expecting app teams to know or select the right infrastructure CI is unrealistic, and changing CIs to force routing usually creates more confusion.

A common, workable pattern is:

• Tier 1 sets the BSO → routes to the app service group

• The app service group investigates and, if needed, manually reassigns or creates a task/problem for infrastructure

• The Incident keeps the same BSO / application service for consistency and reporting

• Infrastructure details stay largely hidden from the broader org

Dynamic CI groups are better for impact analysis and visibility, not fine-grained escalation routing.

Bottom line: CSDM is about clarity of what’s impacted, not fully automating every escalation path. Process boundaries usually work better than trying to encode all escalation logic into Service/CI relationships.

@mejasonroar - Please give a Thumbs up if you find Helpful my friend!

[Barry Kant · Accepted solution]

Hi mejasonroar,

I see 2 different entry points where I expect a different 'behavior'. 

We can have incidents (tickets) from consuming parties. (different channels) -> 1
We can have incidents (tickets) from providing parties. (different channels) -> 2

Note: the Service Delivery domain split is an imaginary split for ease of explanation.

• 
  1 - Consuming parties: Incoming tickets via:
  Chat, Portal or phone
  The Configuration Item is an employee asset, or unknown.
  The Service Offering is selected, given or derived by logic. (this is a Business Offering)
  The Service is the parent of the Service Offering.
  The Assignment Group is the Support Group of the selected Service Offering (or otherwise a fail over group like a Service Desk).
  
  2 - Providing parties: Incoming ticket via:
  Events, back end, integrations
  The Configuration Item is known in most cases. 
  The Assignment Group is the Support Group of the selected Configuration Item.
  So the Technical Management Offering can be derived from the Dynamic CI Group membership of the CI. (which relates to a Technical Management Offering).
  The Service is the parent of the Service Offering.
  
  
  The filtering of the Configuration Item based on:
  the selected Service Offering is not easy as it might be different from a Business Offering point of view (via 1 or multiple underpinning Service Instance relationships) than from a Technology Management Offering point of view (via 1 or multiple Dynamic CI Group relationships). 
  Similar of the filtering of affected CIs (related list) is expected this would more difficult even.
  
  Beside, of that is expected to be the behavior it will require consistent (maturity) level of modeling. 
  
  In the example of "AppX Linux Servers" is kind of similar as a vertical mapping.
  The Horizontal Mapping is the link to the Technology Management Offering for the management (support) ownership. 
  The Vertical Mapping is the link to the Service Instance supporting Configuration Items. (could be Calculated Service Instance, or Tag-Based Service Instance).
  
  For dynamic routing it might be needed to include:
  
  A channel
  The Configuration Item (if not empty)
  The Service Offering (if not empty)
  The Service (if not empty) 
  A fail over group (like a Service Desk)
  
  BR,
  Barry

[mejasonroar]

Thanks for this! It seems I'm trying to force use for two different vectors and that may just not be (easily) possible or prudent.

For your comments about "AppX Linux Servers", ignoring TMOs for a minute, is it logical to make a dynamic CI group for the servers specific to an app and then a corresponding "AppX Support" TMO? That would seem to allow me to then populate all CIs related to AppX, relate them to the TMO, and have that be what the app service runs on. Is that an accurate line of thinkings?

[Barry Kant]

Good day,

That would be an equivalent of a tag-based grouping. 
If tag-based mapping is not used, you can do it with Dyanmic CI Groups.
The support data will not be synced to the individual CIs. 

BR,
Barry