tanner.zinck | 2020-11-18 02:22:45 UTC | #1
Hi,
We are looking for a way to disconnect a callback before the call to the customer participant has started, without any chance of disconnecting an ongoing call.
Currently we get the full conversation object via the GET /conversations/{id} endpoint, check to make sure that the Customer participant has no calls in their calls array, and then issue the disconnect via the /conversations{id}/disconnect endpoint. There's always the chance that in the time between the GET and disconnect the call to the customer has started.
We've discussed potentially adding an additional step before the above where we add a skill that no agent has, wait a brief amount and then do the check and disconnect. This would only potentially work on queues with all skills matching routing setup though.
Is there a better way to stop a callback from routing so that we can disconnect it with confidence that we aren't ending a call?
Thanks, Tanner
Jerome.Saint-Marc | 2020-11-18 17:23:23 UTC | #2
Hello,
I don't think there is a way to avoid at 100% that something like this would happen. I mean that in theory, as there is a delay (code processing time) between the GET /conversations/{id} endpoint and the request to disconnect the callback, the state of the conversation/callback could change (in theory again).
I don't think you can change the skills requested for the callback conversation after the callback has been created/submitted. I am not aware of a Platform API endpoint which would allow this. You would need to schedule a new callback with the new skills (in the same conversation) and disconnect the existing/first callback.
Reducing the time/delay between the 2 API requests (get conversation and disconnect conversation) will reduce the probability it happens. And checking the status of the conversation as well (see below).
- To disconnect the callback, it would be better to use PATCH /api/v2/conversations/callbacks/{conversationId}
With body: { "state": "disconnected" }
- In your check of conversation status:
As you are doing now, check the Customer Participant has no calls in dialing or connected state.
You could also check the status of the callback itself. a) If the Customer Participant has callback(s) in scheduled state, it means that the callback hasn't been put in the Queue yet. So it is safe to disconnect the callback. b) If the Customer Participant has callback(s) in disconnected state, it is also safe to disconnect. I don't think this case/switch will happen as the conversation would be terminated/ended in this case (no calls and no callbacks). c) If the Customer Participant has callback(s) in connected state, then it means the callback is either in the Queue or "connected" to an agent. If the Agent Participant also has a callback in connected state, it means the callback conversation is opened/displayed on his Genesys Desktop (and he might dial soon). Technically, you could still disconnect the callback as well. But if you prefer, you could let the agent make the call as the details of the callback are already displayed on his Genesys Desktop.
Regards,
tanner.zinck | 2020-11-18 17:30:00 UTC | #3
Thanks for the quick response!
system | 2020-12-19 17:30:02 UTC | #4
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: 9336