tpratt wrote:
* Our process enforces that once the Group is assigned the only way to change this is to "Assign to Service Desk" action. We put this in place to prevent "queue manager wars" - something I have seen in other organizations before my new company.
You could make another group field for this logic on assignment, allowing you to have the "real" assignment group field null at times. Let's call this 2nd assignment group "locked group", hopefully I'm not confusing what you need to restrict.
A new ticket is assigned to a specific group, without analyst. So now the ticket can be assigned to a worker bee within that group, OR the worker bee can assign the ticket to another bee, OR maybe assign it back to his own group. Imagine the only available option on the assignment window is analysts within his own group, and the group field is Read Only (and null, for now). The "current user" creating the assignment is a worker bee or manager, and THEIR current group is always copied to the "lock group" with a rule. This would allow the assigned user dropdown to be filtered when the real group is NULL. In the event he wants to assign the ticket back to his group, he simply leaves the assignment user field blank, and the process detects a NULL analyst and would copy the assignment group from the lock group.
I am regretting our mandatory requirement of having a group on assignment more and more. It's not mandatory on the OOTB window, and making it so caused headaches for us.