The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Promoting an incident to P1 or P2 assigns the ticket to the Major Incident Management Group

IanW27934052924
Tera Contributor

When we promote an incident ticket to a Major Incident it auto assigns it to the Major Incident Management Group. (MIMG). 

This causes us a problem when it comes to reporting on resolver group for Major Incidents as the vast majority of MIs will sit in the MIMG queue instead of the queue that resolved those incidents. 

 

Should we switch off auto assignment of promoted incidents to the MIMG?

9 REPLIES 9

Chaitanya ILCR
Mega Patron

Hi @IanW27934052924 ,

I think this is the name of the property which assigns the Major incident to the specified group

sn_major_inc_mgmt.major_incident_management_group

 

if you want to switch off remove the group sysid value from the property value

 

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

 

Dr Atul G- LNG
Tera Patron
Tera Patron

Hi @IanW27934052924 

There are two approaches here:

  1. Yes, you can switch off the auto-assignment by changing the appropriate property.

  2. If you disable it, the incident will remain in the role/lever group, which means the MIM team will not be accountable for the incident. The purpose of auto-assignment is to assign the incident to the MIM team so they can take end-to-end accountability.

You can manually revert the assignment group once the issue is resolved, but be aware that there might be some SLA/OLA defined when the incident is assigned to the MIM group.

*************************************************************************************************************
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.

Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]

****************************************************************************************************************

The problem with the approach you outline is that the MIM group doesn't resolve incidents, it manages them. Reporting on resolution then becomes a problem. I guess the answer is for the MIM team to manually reassign to the resolver group - however when a backlog builds up this becomes troublesome and affects reporting. MIM can take responsibility and manage an incident without it being assigned to them in the ITSM tool. 

 

Hi @IanW27934052924 

I agree with you — MIM is not really a resolver group, but more of a managing group. The question now is:

  • Do you have more than one MIM group?

    • If yes, then I suggest creating a new field specific for MIM and using that field to track/point to the right MIM group. That way, you can clearly see which MIM group is managing a given incident.

    • If no (only one MIM group), then why are we struggling? We can assume (and it’s a fact) that this single MIM group manages all MIM-related incidents.

But another layer to this is: who inside the MIM group is actually managing the incident? Since a group is just a collection of users, if there are multiple MIM groups or multiple users, you need to unfold these scenarios carefully to arrive at the right approach.

*************************************************************************************************************
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.

Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]

****************************************************************************************************************