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!