Agent Chat - Assign Interaction to all agents (First come / First Serve) or Restart Queue?

Sam190 · ‎03-20-2020

Hi,

I am currently setting up Agent Workspace and Agent Chat in my instance, and it's basically almost fully setup. I am having an issue with how interactions are provided to agents which seems to be a known issue that's been fixed in New York. Our instance currently uses Madrid.

Here's the hi ticket for the issue: https://hi.service-now.com/kb_view.do?sysparm_article=KB0754172

The resolution would be to continuously clear the queue from the awa_work_item table or to increase the timeout time, but this isn't really a solution for us.

The OOTB process for Agent Assignment is the following:

1. User requests live chat with Agent.

2. Agent receives request in Agent Workspace, and if not accepted within a minute, it moves the chat request to another agent.

This process is perfectly fine, but there are some issues that come with it. If no agents accept the request, the user will be stuck in an infinite wait-time of "Routing you to a live agent..." despite the fact that no agents can see his request anymore because they've all timed out.

I would like to know if there's a way to get one of the following functionalities in place, I've searched all over and couldn't find a solution.

1. Once all agents reject the request, it would restart the queue; effectively trying to get another agent to accept it, instead of keeping it in limbo. (Possible Solution: OnChange Client Script or business rule to mark work item as cancelled, which will put it back to Pending Accept when the item state is set to Queued [No Agents Accepted])

2. If all agents reject the request, kick user out of chat queue and tell them to try again later.

3. Assign a chat to all online agents, and whoever accepts first gets the chat (Timeout 1 hour)

Let me know if there's a solution that doesn't require scripting that I might have missed. I only need one of those 3 to work.

Sam190 · ‎05-19-2020

Hi Meenat!

Of course I can.

1. Create an event in the registry for the Work Item table (awa_work_item).

2. Create a Script Action that will be linked to the event above with the following code:

// A small delay because state is set to queued when moving from one agent to the other
gs.sleep(5000) 

var gr = new GlideRecord('awa_work_item');
gr.get(current.sys_id); // Work Item ID
gr.query();

// Check if the state is Queued after 5 seconds of it turning to Queued.
if(gr.getValue('state') === 'queued'){
     gr.state = 'cancelled';
     gr.update();
}

3. Create a business rule that will launch the script action above when a work item is set to 'Queued'

When : Async on Update

Condition: State is Queued

Script:

(function executeRule(current, previous /*null when async*/) {
	gs.eventQueue('Check if State is Queued', current, gs.getUserID(), gs.getUserName());
})(current, previous);

Hope this helps!

View solution in original post

Jacob Saaby Ni1 · ‎11-24-2020

Hi Steve.

I sure do. There's an ACL blocking that. Here's how to get around that:

Elevate your role to security_admin
Go to Advanced Work Assignment -> Settings -> Reject Reasons
Click on Time out
Click the tripe lined menu -> Configure -> Security rules
Find the ACL for awa_reject_reason/write
Enable "Admin overrides"
Save the ACL

You're now able to update your Reject Reasons. I assume it's a bug that the ACL doesn't enable admin override. At least, it makes no sense to me that as admin I'm not able to edit my reject reasons.

I tried as awa_admin as well (user had both admin and awa_admin), but that didn't actually let me edit reject reasons. Haven't spent more time looking into that, as the admin override works 🙂

Steve Kelly · ‎11-25-2020

Thanks Jacob, although it looks like the ACL conditions specifically call out that the Time Out reason should not be edited. I may open a HI ticket to ask for the reasoning behind that.

If I do edit the 'Time out' rule to be Reassignable, my understanding is the end user will keep being looped back around to the available agent(s) until they accept, is that correct? Whereas, without the rule being reassignable, the user will just be left on the 'Transferring to live agent...' , message perpetually, or until another agent becomes available?

Jacob Saaby Ni1 · ‎11-26-2020

Hi Steve. No problem.

I don't know if it's a bug or not. I assume it is, because otherwise it would defeat the purpose of being able to make the reject reasons reassignable.

My understanding (and experience) of what happens is the same as yours.

Steve Kelly · ‎11-30-2020

Just confirmed with HI, that ACL restriction is a legacy restriction so it is OK to use your Admin override workaround. I think they will fix it in Paris Patch 4. Thanks again!

Reisha George · ‎10-05-2021

Hi Sam -

I am having the same issue, but not sure if I understand your solution. What are the details on setting up the event in the registry?