Follow up of Event misidentification when agent rejects Conversation or it is requeued, opened as suggested by Genesys Support as the original thread is closed.
Hi there,
We’re encountering challenges on our platform when trying to accurately track the state of conversations using Genesys Notifications API events. Specifically, there are issues when conversations are rejected, transferred, or requeued, making it difficult to determine when a conversation has ended.
Issues Observed:
- Event Misidentification on Reject:
When an available agent rejects a conversation, we receive the event:
{ "id": "v2.detail.events.conversation.${conversationId}.user.end" }
This event is misleading because it indicates the conversation has ended, but it has only been requeued to another agent.
- Edge Cases with Queue Transfers:
• Receiving Multiple ACW Events:
When a conversation is transferred to a different queue, we receive user.end with "disconnectType": "TRANSFER", which helps identify the transfer. However, after the transfer, the agent who performed the transfer can still trigger v2.detail.events.conversation.{id}.acw for the same conversation. This creates ambiguity because our system interprets the acw event as the end of the conversation, even though it’s continuing in a different queue.
Our current workaround involves maintaining state and ignoring acw events if a preceding user.end event with "disconnectType": "TRANSFER" was received. However, this adds unnecessary complexity and doesn’t seem like an optimal solution.
- Session vs. Conversation Concept:
In our system, each chat initiation creates a new session per user. However, Genesys Open Messaging uses the same user ID for all interactions, and conversations are threaded. Our concept also includes a “handover state,” where the user is talking to an agent. We need to know when the agent has truly ended the chat to remove the conversation from this handover state.
Given the threading behavior, we’re unsure if we should maintain the handover state indefinitely and recover it on user reactivation instead of ending it entirely.
- Open Messaging Forwarding Issues:
We’ve also observed scenarios where Genesys events forwarded to our system through Open Messaging were not received, and it’s unclear why. For example, no request reaches our system logs, even though events occurred on Genesys’ side. Debugging these issues is challenging without better visibility or tools.
Questions:
- Tracking Chat End:
Which event can we reliably use to track when an agent has resolved a chat, distinguishing it from requeues or transfers?
- Best Practices for Transfers:
How should we handle acw events after a transfer to ensure our system doesn’t misinterpret them as the end of the conversation?
- Threading Configuration:
Are there recommended settings or best practices for handling threading with Open Messaging when needing precise conversation state transitions?
- Debugging Open Messaging Issues:
What’s the best way to debug scenarios where Genesys events are forwarded but don’t appear to reach our system?
We hope this provides enough context for our use case. Any guidance or recommendations to handle these challenges more effectively would be greatly appreciated.
I really appreciate any help you can provide.