Please note I am not sure this post is in the right section (Plateform API vs Web Messaging), please move it if not correct.
We are having an unexpected behavior on websocket notifications: when an agent is in ACW, any updates on customer participant data is not sent thought websocket.
Steps to reproduce:
Subscribe to v2.users.{userId}.conversations throught websocket (Notficiations API)
Trigger a call => we are getting notified via websocket
Call PATCH /api/v2/conversations/calls/{conversationId}/participants/{participantId}/attributes with correct conversationId and participantId corresponding to purpose="customer" => we are getting notified via websocket
Hangup and go to after call work (queue is setup with Mandatory, Discretionary) => we are getting notified via websocket
Call PATCH /api/v2/conversations/calls/{conversationId}/participants/{participantId}/attributes with correct conversationId and participantId corresponding to purpose="customer" => we are NOT getting notified via websocket
It looks like a bug to me : can you check this one ?
Thanks.
Please note that is the participant corresponding to purpose="agent" is updated in ACW, then we are getting notified via websocket
Thanks for reaching out. This is the right place. I am going to pass your forum post but I suspect that once your agent is going to ACW the "conversation" is considered ended and from a conversation lifecycle the conversation is ended and no further events will be published. You can still update things like the participant attributes, but from a system perspective, the conversation is done.
Let me send this to the dev team and see if I can get more clarification.
Thanks,
John Carnell
Director, Developer Engagement
From an API perspective, 'GET /api/v2/analytics/conversations/{id}/details' will only returned a 'conversationEnd' attribute if ACW is completed, which makes me feel the conversation is ended once the ACW is terminated.
Hi @NicolasP, if the agent is still in ACW when the conversation is being updated (and the conversation shows in the agent's roster to the left hand side in the UI), the notifications should arrive.
If this is reproducible can you open a support case with the region, org, interaction IDs? It will help us figure out what you're experiencing. Thank you!
Sorry, I have an additional follow up to further clarify what I got wrong.
Current implementation is that if you're connected, you get everything. Once you disconnect, you only get updates for yourself.
In an example like you transfer a call to another queue, you go disconnected, you might finish ACW, but the conversation can go on to be routed, transferred, held, updated, etc all while you've moved on, and this logic skips notifications being sent to the user for maybe a long time that don't matter.
So because the attribute updates belong to the customer, it's not an update related to the agent, thus the websocket notification is skipped. I hope that helps clarify!
Can you clarify "Once you disconnect, you only get updates for yourself."? Are we talking about disconnecting the call or the websocket session? To make thing very clear for us, can you tell us if Agent #1 should receive notifications related to step #4 in the following scenario:
Agent #1 subscribe to "v2.users.{userId}.conversations" topic.
Agent #1 answered an ACD call from a customer.
Customer hangup the telephony call, Agent #1 then move to ACW state.
Agent #1 calls "PATCH /api/v2/conversations/calls/{conversationId}/participants/{participantId}/attributes" with correct conversationId and participantId corresponding to purpose="customer".
Specifically, I meant disconnected from the call (or any other communication type) - not the web socket
Because step #4 involves an attribute update to the customer participant, not the agent's participant, I don't believe they would receive the update. The agent was disconnected in step #3 when the customer hangs up and moves them to the ACW state.
If the situation was different and the attribute update was to the agent's participant, then I believe they would see the update. So as a workaround, any update could be made to the agent's participant to sort of "force" an update notification down to them.
