How to prevent Incidents from re-routing through AWA.

[brianmelvin]

We currently have AWA / Workspace setup for incidents. We're finding that whenever an incident is escalated to another team, AWA picks up the item again and attempts to route it. This causes the escalation to be undone once an agent accepts the work item through Workspace and the incident is reassigned back to the help desk. 

I was told by ServiceNow support this might be an known issue, but have not heard back definitively on my HI case. 

Anyone else run into this issue? 

Here's our configuration:

Service Channel:

Queue:

Assignment Eligibility Pool:

Assignment Rule:

[John Green2]

Hi brianmelvin,

Yes, I experienced the same. I don't know if that's intended functionality, but I resolved my problem by simply setting the utilization condition on the channel, to 'State is New'. That way, only incidents in the 'New' state qualify as active work items. Once the incident has gotten escalated to another team, the incident automatically enters the 'In Progress' state, and therefore it won't get routed back to the agents again.

Interestingly, when I created a new service channel based on a table other than Incident, the behavior was different. The only way I could get the item to be routed back through AWA in that case, was to clear the assignee field.

Best wishes,

John.

[brianmelvin · Accepted solution]

Resolved - ServiceNow support found a known issue (PRB1374222) where the Record Watchers [sys_rw_action] related to AWA (where Action Prefix = 'awa-eligibility-responder') were not updating after modifications to the service channel.

In my case, I found that my record watchers didn't include the most recent conditions I had added to my Service Channel. 

The following link can be used to query the AWA record watchers:

https://<your instance>.service-now.com/sys_rw_action_list.do?sysparm_choice_query_raw=&sysparm_first_row=1&sysparm_list_header_search=true&sysparm_query=table%3Dincident%5Eaction_prefixSTARTSWITHawa&sysparm_view=

SN support provided the following script that can be used to rebuild the record watchers in this scenario:

sn_awa.ServiceChannelUtils.deregister("<your service channel sys_id>");
sn_awa.ServiceChannelUtils.register("<your service channel sys_id>");