Hi Raju,
A good starting point is usually the Conversation ID and approximate timestamp. From there, I would use Conversation Details to establish whether the interaction reached the expected flow and queue, how it was routed, and where it stopped progressing.
If the interaction reached the queue but was not offered to an agent, I would check the agent state at that time - On Queue/routing status, queue membership, utilization/concurrency, skills and routing configuration. Capturing the agent state around the time of the issue can be particularly useful, as their current availability may be different by the time the issue is investigated.
For messaging channels, I would also check the inactivity/TTL configuration. Depending on the configured inactivity handling, conversations can be disconnected or rerouted after a period of inactivity, which can sometimes appear to be a stuck or disconnected conversation.
For Web Messaging specifically, I would then look at the deployment/configuration, inbound messaging flow and, where appropriate, browser console/network logs.
My general troubleshooting path would be:
Conversation ID/timestamp → Conversation Details → Architect/queue routing → agent availability/utilization → inactivity/TTL → channel configuration/logs.
If escalation to Genesys Support is required, having the Conversation ID, correlation ID and relevant console/network logs available can make the investigation much easier.
Hope this helps!
------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------