Poulain_Mathieu | 2018-07-30 02:52:21 UTC | #1
We are currently using API notifications to get the status of our agents on a dashboard. When an agent is doing a callback, we are subscribing to: v2.routing.queues.<id>.conversations.callbacks and the we follow the status. However once the call is over, the callback status is still interacting and not ACW. Is it a bug or normal behavior?
tim.smith | 2018-07-30 13:22:36 UTC | #2
the callback status is still interacting and not ACW
What properties are you looking at to determine the "status" of the callback?
Poulain_Mathieu | 2018-08-01 07:29:59 UTC | #3
Hi Tim, We are checking the following: endtime is set state is disconnected wrapupRequired is true It works well in the case of a call, but for a callback the notifications we get are the same, so we can't distinguish the current state.
tim.smith | 2018-08-01 12:50:05 UTC | #4
It may be worth reviewing how to handle a callback: https://help.mypurecloud.com/articles/place-transfer-dismiss-callback/
It sounds like you're misunderstanding the flow of a callback. Try handing a callback and observing the events you receive. Take special note that the call and callback are separate media entities in the conversation and are handled and wrapped separately.
Poulain_Mathieu | 2018-08-02 05:55:02 UTC | #5
Hi Tim, I guess what we were missing is the understanding that the call and callback are two different media. However in the end it is one business action. Also I realize that from Purecloud logic, the ACW only makes sense for the call. The call back is a kind of container for one or more calls to the customer. Right? About the call media, I don't find any, but do we have any hint that the call is made based on the Callback in the notification? I would like to avoid to call a get conversation Details each time we get a call notification to make sure if it is linked to a callback or not.
tim.smith | 2018-08-02 13:17:26 UTC | #6
Poulain_Mathieu, post:5, topic:3272
Also I realize that from Purecloud logic, the ACW only makes sense for the call. The call back is a kind of container for one or more calls to the customer. Right?
Right. You wrap up the voice call only. In analytics results, you'll see the wrap up code applied to both the call and the callback.
do we have any hint that the call is made based on the Callback in the notification?
There will be both a callback and a call in the same conversation.
vitaly | 2018-08-05 20:51:34 UTC | #7
You need to disconnect callback explicitly.
Poulain_Mathieu | 2018-08-06 04:58:19 UTC | #8
Thank you both. In the end I understand what we were doing wrong. We were separately listening to v2.routing.queues.id.conversations.calls and v2.routing.queues.id.conversations.callbacks In this case the event given by .calls are not giving any info about the callback, hence our troubles. We need to listen instead to: v2.routing.queues.id.conversations and then filter the callbacks/calls and other media events... Then if we have both a call and callback at the same time we can know that a given call is linked to a callback.
system | 2018-09-06 04:58:20 UTC | #9
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 3272