Set assignment group if empty but someone is assigned

jesse-csu
Giga Contributor

Our incidents are driven by the category/subcategory to route to the correct assignment group. The issue is some users tend to assign themselves to the incident prior to submitting the incident and this ends up clearing out the assignment group field. So the incident is then sitting in no assignment group (empty in this case).

I am looking for a way to prevent this. Some of the options I have tried are:

 

I tried the client scripts posted here and they only seem to work if the assigned to field is empty. If there is someone assigned, it does not work.

I have also tried setting an assignment rule using assigned to is not empty and assignment group is empty, but that does not work.

I also have a UI policy on the task table in place to make the assignment group mandatory but that is not helping either.

 

Any ideas are much appreciated. Thanks in advance.

7 REPLIES 7

TrevorK
Kilo Sage

Reading your situation, it sounds like you do not want anyone to every use the assignment group field. As well, because of this, you do not want anyone assigning themselves an Incident unless there is an assignment group populated. My post below works on this assumption.



With that said, I can think of a couple different solutions:


1) Using a UI Policy you can make Assignment Group and Assigned To read-only (look for a field the system sets upon save) when the Incident has not been saved. This would provide an easy-to-understand way for the user to know they cannot use the Assignment Group/Assigned To, because it is greyed out.


2) Use a UI Policy to watch for changes to Assigned To, then if it was changed when Assignment Group is empty, roll back to empty. You can use the scripts feature here if need be.


3) ACL - the preferred way to do this because it performs way better. If an Incident does not have a state (or any other field that is set upon submit), make the Assigned To/Assignment Group read only. I think this would work, and ACLs are preferred over UI Policies.



#3 is my preferred - the ACL is a great way. This works under the assumption it is going to exist in all cases. I have not done an ACL for this before. However, I have mocked it up in demo008. It may not be the cleanest, but what it searches for is when "caller" is empty, the assigned to/assignment groups are read only. You would replace "caller" with another field.



There may be better ways to do this, but I only had a couple minutes to whip it up. So check it out - with the ACLs it will be a lot quicker than UI Policies. Hopefully I understood your question and helped!


Thanks much for the input Trevor. I think the ACL will work. I checked it out in the demo008 and then tried it in our dev instance. Making the assigned to field read only may very well prevent the incidents from getting sent to an empty queue now since the user cannot assign them-self beforehand. I will try an update this with results at a later time after I see how it works out in production.


After setting the ACL I found out that the Incident would not let you assign yourself to it after it had been submitted. I simply added a condition to the acl for 'state' 'is one of' and the states such as active, waiting for user info" etc.. It is working out well. Thanks again Trevor.


dwolf
Giga Expert

Hello Jesse,



What is the default group when the incident form initially loads (ie when you click "Create New')?



Thanks.