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

mejasonroar · ‎12-22-2025

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.

Barry Kant · ‎12-23-2025

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

View solution in original post

Mathew Hillyard · ‎01-01-2026

@mejasonroar

This is why guiding users to the service offering as the entry point is a better approach than trying to pin down the CI. It depends upon the organisation of course, but I've generally found more success making the Service Offering mandatory on creation of an Incident, but the CI field mandatory only on resolution, where knowing the causal CI could help trend analysis of Incidents and also Problem Management. Otherwise people just end up putting anything in the CI field - which is unhelpful, even if you are limiting the available CIs to those that belong to a Service Instance.

As @Barry Kant has mentioned, it is a good practice that business-originated incidents reference business service offerings and technology consumer (as in people building or creating services), or automation/integration-based incidents usually reference technology management service offerings (I say usually, because there is still debate as to whether services like desktop support are business or technology management, but that's another story...

As for DCGs for CIs that belong to an app, this is typically only used when Discovery is not yet in use as a convenient way to define a Service Instance based on queries or a manual selection of CIs. If Discovery is running and particularly if Service Mapping is available, then either a top-down Application Service (in this context I'm calling a Service Instance child record what it is, or an Application Service) or if cloud based a Tag-Based Application Service are more appropriate.

I hope this helps!

Mat