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.

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.

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.

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

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.

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.

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.