Issue with populating the Assignment group based on Service Offering and Configuration Item

[Suggy]

OOTB we have a Business rule "Populate Assignment Group based on CI/SO" which populated the Assignment group based on SO or the CI.

We have multiple Service offerings based on region. Each SO has got region wise Service Desk groups.

The have also populated the Support group details for the CIs

Problem statement:

On the INC form, both SO and  CI is populated. Based on the above script logic, the support group of the CI takes precedence.

But we want the incident to be routed to the respective Help desk queue first.

Should I customize the script to meet the requirement? (Generally we avoid modifying OOB scripts). 

And this is a general situation in every org (multiple SOs will be there right), How are you handling this situation today? 

[Uncle Rob]

So they way I think of this is:  If you want CIs to go to the "right group", and the "right group" is the same as owns the SO, then simply change all the CI's so their new support group is the SO, and then you don't have to incur tech debt changing assignment mechanics.

Its a data problem more so than a technical problem, so solve it at the data level.

[Suggy]

Exactly, its not technical problem but more towards data/process. I have workshop in following weeks to discuss on this topic, so meanwhile wanted to check in community how others are handling this situation. Thanks for your inputs @Uncle Rob 

[Michael Dul]

Hi Suggy,

I can share how we approached the problem in the past. I use the principle of designing Data based on its meaning/insight and then looking into the process/functionality.

1. I am not a big fan of putting Service Desk on the offerings. I would keep them separated as they are a Function (in my book) and are shared. You could use routing rules to navigate to proper SD irrespective of Offering. We have in the past used an attribute on the offerings to indicate if Shift-Left was performed which we used to determine if Service Desk should be involved or if Incident should be routed to support group instead.

2. I would put on the offering the primary group responsible for that service

3. I would use the cascading if you need the same information on every CI

4. Alternatively you can disable the cascading and keep on CIs bypass groups, aka. Specialised groups for every CI in scope

5. I would avoid changing the script and do this as a last resort only.

in such case in INC you would have, your SD from routing rules, your primary support of your service, and when you know the CI - a support group from there. There is of course always a question of do you allow offering and CI’s offering mismatch but that again is a process question.

hope this helps.

Best regards,

Michael

[Suggy]

Hi @Michael Dul Thank you so much for sharing your inputs.

At the right time you bought the topic of 'Shift left' approach.

At the moment we do have some concerns around the OOB Business rule "Populate Assignment Group based on CI/SO" 

Using this, most of the incidents are landing directly to L2/L3.

Previously customer was assigning the incident to the help desk group by default but now with the BR, it has introduced chaos.

We have workshops in coming week to discuss on the process.

Having said our problem, can you share your inputs on that? And can you elaborate more on this statement "We have in the past used an attribute on the offerings to indicate if Shift-Left was performed which we used to determine if Service Desk should be involved or if Incident should be routed to support group instead."

[Suggy]

Anyone else who can share your views on this ?