Automatic return to queue after unanswered call

Hello,

  • If the agent doesn't take the call and miss an ACD interaction, the call will certainly be transferred to another agent, then he will be prompted to go back to the On Queue status or return to the Available (non-ACD) status by going Off Queue.but the agent will remain blocked, it's up to him to manually put himself back in the queue.
  • as there is no automatic solution to apply a rule, for example, after 3 seconds, the system will automatically put him back in the queue,I tried to implement this logic (recommended in community Genesys using Process Automation Trigger and Workflow as follows:
  1. Create a Data Action to change the user status to IDLE

Reference: https://developer.genesys.cloud/useragentman/users/#put-api-v2-users--userId--routingstatus

  1. Create a Workflow that utilizes the Data Action created above

  2. Add a Trigger for the topic "v2.users.{id}.activity" that activates when an agent's status changes to "Not Responding". Configure it to use the previously created Workflow to change their status to IDLE

Reference: https://developer.genesys.cloud/platform/process-automation/trigger-examples/user-in-away-status

If it can be useful: we have implemented the same suggestion provided by Maxim; but with a small variation in the Workflow invoked by the trigger: we introduced a 5 minute delay, the invocation of a Data Action to check if the agent's status is still in NOT RESPONDING and, if so, we execute the call to the Data Action that sets the RoutingStatus to IDLE.

but I think it's not working automatically, while the dataaction works correctly by testing it directly.

here's the data action config:


trigger config :

workflow config :
image

could you please help me to fix it
thank you

First thing to check is that your trigger is enabled. I only ask because I forgot to do that about a week ago, which took a while to figure out.

Next up is to use the architect replay mode to make sure that your trigger is actually causing your workflow to execute. If it isn't firing at all then again it could be that the trigger is disabled (my problem last week) or maybe the criteria are incorrect somehow. If it is firing you can make sure that the input variables are what you expected.

--Jason

yes, it's the first thing I checked . the triger is already enabled.


However, when checking the Flow execution history, I didn’t find anything.

Hello,

"NOT_RESPONDING" is a routing status.
So I think your condition should be on "routingStatus.status" (== 'NOT_RESPONDING').

Regards,

HEllo, thank you. I have a data now. but I think I should modify something in the data action to be able to get the userid:

Hello,

Make sure to define your Flow.userId variable with "Input to flow" enabled/checked.

Regards,

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.