Any CSDM experts? Issue in determining the 'Assignment Group' on Incident form.

[Suggy]

We have 'Support group' populated on the 'Service Offerings'.

See the definition of it in docs:

Support group

Group that provides expert support to the service offering. This group is usually a level 2 support team.

We have also populated the Support group on every Infrastructure CIs.

Issue

We have a service offering say 'ABC' where the support group is 'GROUP ONE'. they are the group of experts to support the service offering.

Above service offering is linked to 'Application service/service instance', which is tied to many Infra CIs like Database, servers etc.

Now the monitoring tool has created an Incident with CI populated as 'Windows server prod', and the support group has value as 'GROUP TWO'

Question is - Which group should support in this case? GROUP ONE or GROUP TWO?

PS - I am asking this question wrt ServiceNow's recommendation on auto assigning the incidents using CMDB and CSDM framework. So we have filled all the types of groups in all the CI types.

There is also an OOB BR "Populate Assignment Group based on CI/SO" which takes the precedence of using the CI's support group in case of support group present for both CI and SO.

On what context ServiceNow has designed this? How can this framework assign the incident blindly (based on BR?)

To me, auto assigning of incident based on CSDM framework will never work for anyone. Its just adding more and more confusions...... unless anyone has something to say or defend.

I would be happy to learn if I am missing anything.

[CFrandsen]

As I see it, there is not a single "correct" answer to your question - as it's related to how you structure your support organization and do the impact abstraction on the reported incident....

What is most urgent, the BSO or the CI (Chicken Vs Egg)

The business rule "Populate Assignment Group based on CI/SO" gives precedence to the CI-level support group when both CI and Service Offering (BSO) are populated.

The reason is:

• CI-level support group typically represents the resolver group that is closest to the technical fault — they are usually L1/L2 teams who have responsibility for that specific infrastructure element.
  
  

• Service Offering (BSO) support group reflects functional ownership or service accountability — usually L2/L3 teams or Service Owners who are responsible for the overall service delivery, but not necessarily for technical troubleshooting.

Because incidents often require immediate technical resolution first, the system prioritizes the CI-level group (GROUP TWO in your case) by default.

Of course, this behavior can be customized depending on your organization's preferred process (e.g. prioritize BSO support group, use conditional logic, or implement escalation flows).

Your final question regarding the HELP DESK, sounds like a requirement to either do a "shared resolution" between the CI Support Group and the "BSO Support Group / HELP DESK".  or split it into two streams ( one for business attention and SME involvement, and 1 for fixing the technical issue). 

[Suggy]

Hi @CFrandsen Thanks much for those inputs. It helps 🙂

If you could also provide your inputs on these 2 posts, it would be really helpful

How are you using Service + Service offering + CI ... - ServiceNow Community

Which variables to show on Incident record produce... - ServiceNow Community

Thanks again 🙂

[CFrandsen]

I've added a few inputs to the above listed questions 😉 
Feel free to mark them as helpfull  and/or accepted answers if they fulfill your question(s).

[Jonathan CABY]

Hi @Barry Kant ,

Your suggestion is mostly what I had in mind.

But we didn't succeed to answer to another one : what about Service Level Management for a "Business Incident" to reassign to "group 1" or "group 2" ?

Let's say we leveraged the SLM where the SLAs use Service commitments attached to Offerings.

If we have a new Business incident, with a BSO, and we need to involve a Group 1 or 2 after Service Desk's first analysis, what should we do to get those groups related OLAs created ?

• Modify Service and Offering of the incident for relevant TS and TSO ? (but we would lose Business information)
• Add TSO to "Impacted Services" related list ? (but the standard config does not reassign from that, and does not create OLAs)
• Create a new Technical Incident linked to the Business Incident ? (then, the Business Incident would stay assigned to Service Desk. Would it be the parent ? child ?)
• Something else ?

Best regards,

Jonathan

[Barry Kant]

Hi Jonathan, 

there is a 2 distinctive ways to use commitments:

• Ticket based commitments
• Service based commitments

Ticket based is is you can imagine in the context of the ticket (the incident). In general this is a respond/resolve type of SLA. For a business initiated incident, you want to measure the business agreed SLAs. (the commitments made with the customer). this in general is based on the Business Service Offering in the incident. If you need to track providing parties it needs to be done against Technical Service Offerings. What cannot be done is measure both side in 1 ticket. Meaning, it requires a child incident or incident task to track the providing party agreements, those child incidents/incident task will be made on the Technical Service Offering. 

The Service based commitments are about the service. In general the service availability. This in general is the Business Service Offering in the incident. It requires an outage record for that Service Offering (measuring start/end date delta). These data is collected per time interval like monthly / yearly figures. 

Hope this explains SLM/SLAs a bit. 

BR,
Barry