skansakar | 2016-09-01 18:46:51 UTC | #1
There is a default behaviour in the application that if the user is 'On Queue' and incoming call is missed, we get an alert saying 'Not responding'. Application then changes the user from 'On Queue' to 'Off Queue'.
Is there anyways (in config) not to do this? It will saves users having to changes there status every time this happens.
tim.smith | 2016-09-01 18:29:19 UTC | #2
I'm not aware of any way to do this. However, if this were turned off, the system would assign that user interactions one after another forever because they're still on queue. The agent would be the longest available eventually, so everything would keep trying to alert them over and over again.
To be blunt about it, if the agents don't want to be put off queue, they should answer their interactions. They're causing the problem by choosing not to answer interactions.
skansakar | 2016-09-01 19:16:23 UTC | #3
I agree that they should answer their interactions. But I would like to differentiate between a presence set manually and the presence set automatically due to agent 'Not responding' and taking different actions/alerts based on it.
Based on 'Understanding Presence' article I could make this distinction if I had access to 'ACD Routing Status'.
Looking at it further, I can see that PureCloud application subscribes for "users.{{userId}}.routingStatus" topic but this topic is not returned by the AvailableTopics API (https://api.{{environment}}/api/v2/notifications/availabletopics) or documented anywhere.
Can this subscription topics be used and relied in future versions?
tim.smith | 2016-09-01 19:41:31 UTC | #4
When a user fails to answer an interaction, they are put in the NOTRESPONDING routing status. They will remain in this routing status until they do something to change it; the system will not change them out of that routing status automatically. If a user is OFFQUEUE after being in NOT_RESPONDING, it's because they clicked the button to go off queue.
users.{userId}.routingStatus is a v1 topic, but it will continue to work as long as v1 is still around (it's being turned off this year). I've created AS-788 to migrate the topic to v2.
skansakar | 2016-09-08 15:13:10 UTC | #5
@tim.smith in absence of the routingStatus topic, what else can I rely on to know that the routingStatus has changed to NOT_RESPONDING? (And update agent status)
Does not look like there is a notification message either? What can I do? Any ideas?
Also, do you know when this AS-788 is likely to be done?
tim.smith | 2016-09-08 15:23:03 UTC | #6
GET /api/v2/users/{userId}/routingstatus will return the routing status of the specified user.
AS-788 hasn't been prioritized, so there isn't an ETA at this time.
skansakar | 2016-09-08 15:34:55 UTC | #7
I know how to get it. I actually meant, how do I know when to call it? (i.e. a trigger, notification etc) Don;t really want to be calling he routingStatus API every x seconds to know if it has changed.
Is there a way to get the application to change the presence when this happens? e.g. On ''NOT_RESPONDING' change to 'Offline' Presence or even a new special 'Not Responding' presence. This will then send a notification message (e.g. on change Presence topic ) which I could handle and make necessary actions.
tim.smith | 2016-09-08 15:39:48 UTC | #8
skansakar, post:7, topic:351
I know how to get it. I actually meant, how do I know when to call it?
Use the v1 topic users.{userId}.routingStatus if you want to know when it changes in real time. There's nothing inherently wrong with v1, just that v1 is deprecated in favor of v2. Because there is no v2 topic yet, using the v1 is acceptable in the interim. Just make sure you upgrade to the v2 topic before v1 is disabled. There will be plenty of lead time for people to upgrade to v2 once the v1 end of service date is announced.
skansakar, post:7, topic:351
Is there a way to get the application to change the presence when this happens?
PureCloud doesn't do that OOTB, but your integration can by taking action when you get the routing status notification.
system | 2017-08-28 19:26:54 UTC | #9
This post was migrated from the old Developer Forum.
ref: 351