Genesys Cloud - Main

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
------------------------------

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
------------------------------

All good considerations, yes that is the current state and intent of the Inactivity Handling feature, focused more on Agent efficiency.

Would be good to keep an eye on this upcoming feature, specific to Web Messaging only, where we also allow for configurable "Guest Session Duration": upon expiration, the End-User's session is also "cleared" > https://genesyscloud.ideas.aha.io/ideas/DXWMM-I-7

------------------------------
Angelo Cicchitto
Genesys - Employees
------------------------------

Original Message:
Sent: 03-23-2026 18:56
From: Phaneendra Avatapalli
Subject: Clarification on "Disconnect" Behavior in Inactive Messaging Conversations (Web Messaging)

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
------------------------------

Hi Angelo,

Thank you for sharing the idea voted and subscribed now.

Regards

Phaneendra

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

Original Message:
Sent: 03-24-2026 05:48
From: Angelo Cicchitto
Subject: Clarification on "Disconnect" Behavior in Inactive Messaging Conversations (Web Messaging)

All good considerations, yes that is the current state and intent of the Inactivity Handling feature, focused more on Agent efficiency.

Would be good to keep an eye on this upcoming feature, specific to Web Messaging only, where we also allow for configurable "Guest Session Duration": upon expiration, the End-User's session is also "cleared" > https://genesyscloud.ideas.aha.io/ideas/DXWMM-I-7

------------------------------
Angelo Cicchitto
Genesys - Employees
------------------------------


Original Message:
Sent: 03-23-2026 18:56
From: Phaneendra Avatapalli
Subject: Clarification on "Disconnect" Behavior in Inactive Messaging Conversations (Web Messaging)

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

Great thread - here are a few things that might help:

Why it keeps going back to the same agent:

It's Last Agent Routing doing its thing. By default, queues are set to "Last agent on any queue" so it just sends the conversation back to whoever had it last. You can tweak this in your queue settings or turn it off completely if you'd rather spread things around.

Threading Timeline is your friend:

The Messaging Threading Timeline (defaults to 72 hours) decides how long a conversation stays connected after someone disconnects. Pro tip: if you set this to 0, each new message from the customer creates a totally fresh conversation - new ID, new flow and it won't try to route back to the same agent. 

The customer session thing:

That Aha! idea @Angelo Cicchitto mentioned would let us configure this, which would be nice.

What's working for others:

• Route to an Architect Flow on inactivity to send a proper closing message or re-route back to queue if it was agent inactivity that was triggered as opposed to the customer
  • This may occur if the agent had to step away urgently and limits the customer impact as it allows another agent to pick up the conversation.
• Tweak the Threading Timeline to 0 or something shorter
• Tweak the Last Agent Routing settings based on what you need
• Inform the customers upfront how the inactivity works

Bonus tip:

You can also hit /api/v2/conversations/{conversationId} to grab the disconnect type and see who went inactive - agent or customer. Then you can customize the message accordingly. Like, apologize if your agent went dark vs. a friendly "noticed you stepped away" if it was the customer.

Related thread worth checking out on this feature: https://community.genesys.com/discussion/automatic-handling-of-inactive-messaging-interactions

------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------

When you Route to Architect Flow how can you send a message to the customer and then end the flow without ending the message converation?

------------------------------
Andrew Gregory
Voice System Specialist
------------------------------

Hi Andrew,

Route to Architect lets you select an Inbound Message Flow from the selected flow list.

Within that flow, you can use Send Response to send a final message to the customer, and then use Disconnect to end the conversation.

Hope this helps.

Regards,
Phaneendra

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

Original Message:
Sent: 05-10-2026 18:47
From: Andrew Gregory
Subject: Clarification on "Disconnect" Behavior in Inactive Messaging Conversations (Web Messaging)

When you Route to Architect Flow how can you send a message to the customer and then end the flow without ending the message converation?

------------------------------
Andrew Gregory
Voice System Specialist
------------------------------