Genesys Cloud - Main

 View Only

Sign Up

Back to discussions
Expand all | Collapse all

Clarification on "Disconnect" Behavior in Inactive Messaging Conversations (Web Messaging)

  • 1.  Clarification on "Disconnect" Behavior in Inactive Messaging Conversations (Web Messaging)

    Posted 9 hours ago

    Hi everyone,

    I've been exploring the "Disconnect or reroute inactive messaging conversations" feature in Genesys Cloud and ran into some behavior that I'd love to validate with the community.

    Scenario:

    • Queue configured with Inactivity Handling → Timer + Disconnect

    • Channel: Web Messaging

    • After inactivity timeout, the interaction is marked as disconnected on the agent side

    Observed behavior:

    • The agent is released and can apply wrap-up codes 

    • However, the customer session remains active

    • No "conversation ended" indication is shown to the customer

    • If the customer sends a new message, the interaction is routed again (often back to the same agent)

    Questions:

    1. Is this the expected behavior - that "Disconnect" only ends the agent's participation but not the customer's messaging session?

    2. Is there any native way to truly "close" a messaging conversation from the platform side?

    3. When the customer re-engages, what determines whether it routes back to the same agent vs. another agent?

    4. How are others designing around this for clearer customer experience? (e.g., inactivity messages, bot handling, Architect flows, etc.)

    Observation:
    This feels less like a true "disconnect" and more like:
     "End agent engagement and free capacity, while keeping the conversation thread alive"

    Would really appreciate hearing how others are handling this in production - especially for SLA-driven environments or where a clear conversation closure is important.


    #DigitalChannels

    ------------------------------
    Minhaj Mubashir
    Technical Account Manager
    ------------------------------


  • 2.  RE: Clarification on "Disconnect" Behavior in Inactive Messaging Conversations (Web Messaging)

    Posted 5 hours ago

    Hi Minhaj,

    From my understanding, this behaviour is expected, the "Disconnect" action is primarily designed to end the agent's participation and free up capacity, rather than fully closing the customer's messaging session.

    One approach that worked well when I tested this the other day was selecting "Route to Architect Flow" for inactivity handling and pointing it to an Inbound Message Flow.

    From there, you can:

    • Send a final message to the customer
    • Either disconnect the conversation, or
    • Place them into a holding/self-service path (e.g. bot or fallback flow)

    It also helps to set expectations upfront (e.g. informing customers that the chat may close after inactivity and they may need to re-initiate).

    This creates a clearer experience rather than leaving the session open-ended.

    Hope this helps.




    ------------------------------
    Phaneendra
    Technical Solutions Consultant
    ------------------------------

    Original Message


Related Content