Event misidentification when agent rejects Conversation or it is requeued

[Nacho]

Hi there,

We’re encountering an issue on our platform where a new conversation arrives and an available agent in the queue clicks “Reject,” the conversation is requeued to another agent. However, at this point, we are receiving the following event:

{ id: v2.detail.events.conversation.${conversationId}.user.end }

This event is misleading, indicating that the chat has ended, even though it’s only being transferred. We also rely on other events like:

{ id: v2.detail.events.conversation.${conversationId}.wrapup }

{ id: v2.detail.events.conversation.${conversationId}.customer.end }

However, none of these seem to clearly indicate when a conversation has been requeued instead of actually ending.

We’ve been attempting to distinguish transfers using logic like:

message?.eventBody?.disconnectType !== "TRANSFER"

This helps us identify if the conversation is being transferred to another queue. Additionally, we had to resubscribe to the Notifications API socket after each queue transfer to keep receiving updates, which isn’t clearly documented.

About the original issue, we receive .user.end without any follow-up event when the chat is reassigned. Worse, once we receive .user.end, we don’t get any updates on the conversation status afterwards, even if another agent picks it up.

Given this, could anyone provide guidance on:

1. Which event should we track to know whether a conversation has ended or is required reliably?

2. Any better indicators in the event payload to distinguish between a true end and a requeue?

3. Best practices for maintaining socket subscriptions when conversations are transferred?

We’ve done some reverse engineering, but we’re hoping for a more definitive solution or better documentation on how these events behave.

Thanks in advance for any assistance!

[Nacho]

Could we please get a reply here? Thank you

[John_Carnell]

Hi,

Personally, if I want to know if a conversation has ended I have to look for the ACW event: v2.detail.events.conversation.{id}.acw. This event fires when the agent specifically applies a wrapup code and this is considered the end of the conversation. I have used the event several times in Process Automation Triggers to kick off workflows when a conversation has officially ended.

Can you provide some more detail on your question about handling notifications for maintaining socket conversations? If you are building a front-end application you are going to be subscribing to the specific conversation and the conversation id will still be stable during a transfer? Some more detail will help guide the question.

Thanks,
John Carnell
Director, Developer Engagement

[Nacho]

Hi John,

Thanks for your reply. This event v2.detail.events.conversation.{id}.acw was helpful in understanding when the agent clicks on done and the chat is fully finished. Although this solves the issue when an agent rejects the chat and another handles it, we noticed that it breaks the scenario when a queue transfer is done. Let me explain:

Our system needs to be aware of and react to different events. One of these is the conversation wrapup. For that, we are listening through WebSocket events with the notifications API topics. We found edge cases within the integration:

• When the agent rejects a conversation. We received the event v2.detail.events.conversation.${conversationId}.user.end; after your reply, it is clear this was not reliable to understand if the conversation ended. Using v2.detail.events.conversation.{id}.acw makes the trick for this scenario

• When the agent transfers the conversation to a different queue. We realised the following v2.detail.events.conversation.${conversationId}.user.end comes with a difference in its body disconnectType: 'TRANSFER', so we understood the conversation transfer happened. Then, I found two issues:

  1. After the transfer occurred and the agent who performed the transfer wrapup the original chat, we kept receiving v2.detail.events.conversation.{id}.acw, so our system understands that the chat ended again. It should not continue when this is false, as it continues in a different queue. Do we need to store a state for this so that we ignore v2.detail.events.conversation.{id}.acw if we detected v2.detail.events.conversation.${conversationId}.user.end came before it with disconnectType: 'TRANSFER'?

In our system, the concept of conversations also works differently. Every time a chat is initiated, we create a new session per user, while Genesys Open Messaging always uses the same user ID. Also, our concept is that a given conversation can be in a handover state, which means the user is talking to the agent in Genesys. Still, we need to know when the agent ended to get the conversation out of that handover state and perform other logic. This makes me think that we might never end/delete the handover state of the conversation to avoid these edge cases, so when the user gets triggered a handover, we recover the previous one rather than try to initiate a new one.

I hope this explanation made our use case more straightforward. Thanks in advance for any assistance!

PS: About the reconnection of the socket we noticed this was an error on our implementation