We found the same thing, remember since the end goal is making the system assign the ticket to the right people, it will not necessarily exactly mirror the teams you have sat in the office if you catch my meaning! This is OK since Techs can be members of more than one Tech Group.
We created some additional Tech Groups where the members crossed over one or more real-world teams, then set the different Tech Group levels to differentiate between the real-world teams.
As an example: ordinarily our Helpdesk are level 1 for all Request Types, we have a Level 2 Application Support team and a Level 2 Tech Support team, both of which usually have have their own specific Request Types for routing tickets.
In odd cases where both of these Level 2 teams might need to contribute to a request, we create a new Tech Group associated to the Request Type which has the Helpdesk Techs as Level 1, our App Support techs as Level 2 and Tech support techs as Level 3. After that you can use custom fields and action rules to route the requests to the right people because your rule can reassign to a different Tech Group level which doesn't throw up the error you see when trying to assign a ticket to the 'wrong' Tech Group.
We have found the work-around to assigning to different groups: Have fun everyone. This is a really good one.
The problem we faced is sending a ticket to another technology group. for instance - Email problem
Application - Email - Outage
This would go to the service desk. After reviewing it is determined to be an issue that is handled by Infrastructure. To get the ticket to infrastructure we would have to re-queue the ticket losing our original request type. that, we wanted to keep, but just send the ticket to another group. Here is how we did it.
Under the areas that are considered Incidents. (items that are broken), we have added additional request type (that is not visible to the client, only the technicians) with specific assignment groups:
application - email - outage - reassignment-Infrastructure
application - email - outage - reassignment-Service Desk
application - email - outage - no reassignment
When the ticket comes in to the service desk, they would work the ticket. if they are closing it, they would choose the request type - no reassignment. If they are sending it to infrastructure, they would choose reassignment-infrastructure. This physically changes the tech group to infrastructure making it a true assignment.
What this does is keep the assignment groups clean, allows for true escalation procedures within groups and ensure that reporting is accurate.
The best way around this is to create a a working tech group with one user that has access to all request types like a manager or an admin. Setup an action rule to reassign to that individual, an action rule to change the request type to one that the actual destination tech group has access to and one more to assign to the destination. The problem is the way you have your request types configured, not the action rules.
Ok, I will look into that one. but to clarify what we are trying to do. and I think I might have stumbled on to the answer so I will list it out in the order we perform the function.
Create a request time for the group we need to assign the ticket to:
application - mortgage - outage - reassignment-Application Support
application - mortgage - outage - reassignment-Operations Support
application - Mortgage - outage - reassignment-Service Desk
application - Mortgage - outage - no reassignment
The customer field application houses all the mortgage applications that we currently use. the problem, multiple groups are involved in the support - as listed above. Majority of the applications are supported by Application Support therefore, if they request How to dosomething, it will always go to them. but if they select Outage, then the issue become a reassignment issue. To stop the other team for touching something that does not belong to them, we have created the action rule to do the assignment for them.
We created the escalation groups within the request types. With that done, we told the action to look at a custom field called Application,. if the field contains a mortgage app called Allregs then the action tells it to assign to the ticket to Reassignment-Operations.
Another action tells the system if the request type is Application-Mortgage-outage and the custom field states AllRegs - then assigned to Reassignment-Service Desk.
Doing it this way, we have not gotten that Level Error (In my last test it did not). Everyone stays in their group so it becomes a group responsibility instead of an individual. and when I need to report on this issue, I am able to determine what happened with the ticket - it was reassigned? etc.
I hope this makes it a little clearer of what we are facing and if there is another way of performing this without doing too much.
The problem is that the request types assigned to the tech groups are restricted to those tech groups. All the tech groups need access. Another way you could do it with your existing setup is to make one manager manager of all tech groups and will have access to the request types but tickets would have to be assigned to that person first before another action rule would assign the call after changing the request type by action rule.
Sorry, I did not respond sooner, but we have looked at that in the current way that our system is setup. Yeah, I can send the ticket to the manager, and now the manager is responsible for providing the ticket information to the appropriate technician. The only way the technician can fully document the ticket and put their name on it as the technician is to re-do the request type where he (the technician) is listed as a technician. So what they did to get reports on a technician that is placed in multiple group? The group who is reporting on their items is listing him under their reports, and the technician's manager is listing him. so, who did the work? The original assignment group with him working for them, or the group that he truly belong to. This become an issue with Definition of Responsibility. This also becomes hard to explain in reporting.
So, for us. We have decided that the important information that would help our organization is not just logging tickets, but being able to obtain Sound Metrics when reporting to management what happened during a period of time. We have already shown our EVP and he is excited with the direction we have aligned this software. Now, we are able to tell him exactly what work was done by each assignment group. We can tell him if a specific ticket jumped around from group to group. We can now soundly show him problems, how many groups were included in the resolution, how long each took, did this become a change.
I would love to let you see what we have done. Maybe it may make more sense seeing it in action as opposed to just seeing it written here.