Control who can select given assignment group

[Soren_Bjorn_And]

Looking for some inspiration:

We currently have our ITSM module set up the default way where any ITIL user can assign an Incident to any Assignment group.

However, some groups are requesting that we limit who can assign to what groups. 

Their suggestion is that the group owner should able to define what other groups are allowed to assign to his/her group(s). However, with 900+ assignment groups in our system I fear the logistical nightmare of maintaining this and also what performance issues it might give if the system needs to run through a long check before any assignment.

So have any of you implemented similar requirements to above and if yes, could you give some insights into how you have done this?

Thank you in advance for any guidance!

[Kieran Anson]

This sounds like a very strange requirement, I'd want to dig further into the WHY to see if it's legitimate requirement.

Something I usually do is create group types and filter what groups are available based on the type. An example being a group type of "incident" can only be assigned incidents. 

[Soren_Bjorn_And]

yeah, we are actually just starting to implement group types for certain case types, i.e. Incident groups for Incidents.

The requirement comes from our company having a fairly decentralised IT Organisation. So for many areas each major business application (of which we have 5000+) is kind of a siloed setup. 
However, some areas, such as our Network infrastructure area have a requirement that all cases for them goes via our Global Service Desk. But since we have 6000+ ITIL users, many teams will just directly assign network related cases to the Network teams without going via the Service Desk. And with 6000 ITIL users, its pretty difficult training them all consistently.

[Kieran Anson]

Ah I had something similar when I first started using SN (I was on the service desk) where 3rd line teams would throw work back to 1st line, or go directly to second line.

We used group types to designate the "level" of the group. When a task was assigned to a group, we'd create a metric instance using metric definition which would capture that group level. We'd then check when a task was re-assigned to make sure it had gone through the appropriate level chain (level 1 to level 2, then to 3 etc). 

Possibly something similar could be used for yourselves as a starting point? An "MVP" of a solution to see if its well received?

[Soren_Bjorn_And]

Yeah, so you didn't prevent it but you made it possible to report on when the process was not followed?