Alignment of Incident Management with CSDM 5

[Alok Kr Gupta]

For incident creation, the recommended approach is,

User raises an incident based on the Business Service Offering which is assigned to the relevant group who owns that service. Upon investigation, if it is found that an underlying technology management service offering has an issue that is causing the user's incident and require the Technology Management Service team to investigate and resolve.    

Now the incident remains with the group who owns the Business Service Offering (tracking end - to end SLA and commitments of the Business offering) and a child incident shall be created for the Technology Management Offering so that relevant team can take action. This Child Incident is assigned to the responsible platform team /group which is defined on this Technology Management Offering with the associated task SLA. (Now we have one SLA with BSO & another SLA for TMO)  

Or an incident task can also be created instead of creating a child incident? ( in this case we will have one SLA with BSO, one SLA for TMO at Incident task level & another similar SLA for same TMO at incident level if an incident is directly raised for TMO )

Please let me know if this is the best approach or feel free to share what other approaches could be explored  in this scenario.

#CSDM5 #Incident

[Itallo Brandão]

Hi Alok,

This is a classic architectural debate when maturing CSDM. You are essentially trying to balance Customer Centricity (BSO SLA) with Technical Accountability (TSO SLA).

Regarding your two proposed approaches, here is the alignment analysis with standard Incident Management and CSDM 5 best practices:

1. The Child Incident Approach (Recommended for "Root Cause" flows)

Your suggestion to create a separate incident for the Technology Service Offering (TSO) is generally the preferred approach, but with a slight twist in the hierarchy logic.

• The Logic: In ServiceNow methodology, the "Technical Issue" (TSO) is often the Parent (Root Cause), and the "User Issue" (BSO) is the Child (Symptom).

• How it works:

  1. The Incident stays with the BSO team (User Interface).

  2. They identify a technical failure and create a New Incident against the TSO.

  3. Link them: The TSO Incident becomes the Parent; the BSO Incident becomes the Child.

  4. State Management: The BSO Incident goes to "On Hold" (Awaiting Parent). The TSO team works on their Parent Incident.

  5. Resolution: When the TSO team resolves the Parent, it cascades the resolution to the Child (BSO), and the BSO team verifies with the user.

• SLA Impact: This gives you exactly what you want.

  • BSO SLA: Measures the total duration (End-to-End) visible to the customer.

  • TSO SLA: Measures the specific resolution time of the technical team on the Parent ticket.

2. The Incident Task Approach (Not Recommended)

Using Incident Tasks for this scenario is generally discouraged for Service Handoffs for two main reasons:

• SLA Complexity: Out-of-the-Box (OOB), SLAs run against the incident table. While you can configure SLAs on incident_task, it complicates reporting and limits the visibility of the "Service Offering" field, as tasks are task-based, not necessarily service-based records.

• Major Incident Scalability: If that TSO failure affects 50 other users, you cannot easily link 50 other incidents to a single "Incident Task." You need a "Parent Incident" record to act as the hub for all affected users.

Summary: The CSDM 5 Alignment

In CSDM 5, the distinction between Consumer (BSO) and Provider (TSO) supports the Parent/Child model best.

• Scenario A (One-off Glitch): If it is a simple fix, you might just Reassign the original incident to the TSO group. (Downside: You lose the separate BSO vs. TSO SLA tracking, using OLAs instead).

• Scenario B (Structural/Service Issue): Create a Technical Incident (Parent) assigned to the TSO Group and link the User Incident (Child). This maintains the cleanest data separation and allows accurate SLA reporting for both the business commitment and the technical resolution.

Recommendation: Go with the Child/Parent Incident approach. Avoid Tasks for Service Offering handoffs.

Hope this helps clarify the CSDM alignment!

If this response helps you achieve your requirement, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.

Best regards,
Brandão.

[Mathew Hillyard]

Hi @Alok Kr Gupta 

The options are, as @Itallo Brandão mentions, Transferring the ticket to the TSO support group, or alternatively creating a separate incident.

This is an interesting question where both possible solutions have strengths and weaknesses.

Creating a parent Incident for the TSO is fine but now the original Incident's resolution SLA is dependent upon the parent incident being resolved. How is this accounted for in the BSO resolution SLA? Does it become BSO + TSO SLA in terms of time to resolve? How does this compare with Incidents that can be resolved at source? Surely they will have a shorter potential resolution time? This can really skew service reporting. It is also problematic in creating a larger number of incidents and slightly obscuring what's happening in Incident management with a web of parent/child incidents. And if the fix requires a change or was caused by a change how do you relate the original BSO Incident to it if that data is in the parent incident assigned to the TSO

Reassigning the ticket is the traditional way to do this - you'd only create a separate incident if the causal CI has a wider impact than a single BSO normally - but this too has issues around accountability and SLA tracking, as well as the potential for getting the reassignment wrong and bouncing the ticket around several groups (although this is a service desk metric via the reassignment counter so could be resolved).

Bear in mind that TSO is not just a provider. They also service technology consumers via the technology service catalog so will already be subject to different types of SLA.

I guess the answer is in the way the organisation wants to track and manage such activities. As is often the case with CSDM, there is room to define more than one approach and remain aligned.

I hope this helps!

Mat