Amazon Connect: How to detect if a chat was ended by the agent or the customer in the disconnect flow?

In Amazon Connect, you can determine who ended a chat session by using the disconnect reasons that are captured in the contact record.

When a chat ends, Amazon Connect records specific disconnect reasons that indicate whether it was the agent, customer, or system that ended the conversation. These disconnect reasons include:

• AGENT_DISCONNECT: When an agent explicitly disconnects or rejects a chat
• CUSTOMER_DISCONNECT: When a customer explicitly disconnects
• EXPIRED: When a chat disconnects due to expiration of configured chat duration
• IDLE_DISCONNECT: When a disconnect occurs due to an idle participant

For your specific scenario where you want to differentiate between customer idle timeout and agent manually closing the chat, you would look for the IDLE_DISCONNECT reason versus the AGENT_DISCONNECT reason.

In your disconnect flow, you can use these disconnect reasons to branch your logic. The disconnect flow runs when the agent or Amazon Lex bot has disconnected from the chat and only the customer remains. Within this flow, you can use the Wait block which has two branches:

1. Timeout branch: This runs if the customer hasn't sent a message after a specified amount of time (customer idle timeout)
2. Customer return branch: This runs when the customer returns and sends a message

For example, you could set up a disconnect flow where:

• If the disconnect reason is IDLE_DISCONNECT, you might send a proactive SMS to re-engage the customer
• If the disconnect reason is AGENT_DISCONNECT, you might route the chat to a different agent

Remember that the total duration of a chat, including multiple Wait blocks, cannot exceed 7 days.
Sources
The chat/SMS channel in Amazon Connect - Amazon Connect
Data model for Amazon Connect contact records - Amazon Connect
Amazon Connect now provides granular disconnect reasons for chats - AWS
Sample disconnect flow in Amazon Connect - Amazon Connect

You can't read the CTR disconnect reason in real time inside the Disconnect flow, so branching on IDLE_DISCONNECT vs AGENT_DISCONNECT the way it's described isn't actually possible. The disconnect reason only gets written to the contact record after the contact is fully closed.

The part that clears up most of the confusion is understanding when the Disconnect flow fires. By default it runs when the agent (or Lex bot) leaves and the customer is still connected. So in the normal case, if you're executing the Disconnect flow, the agent side has already dropped. If the customer closes their window first, the flow doesn't run at all unless you've set DisconnectOnCustomerExit to true in the StartChatContact API, which forces the agent to disconnect too so the flow runs consistently either way.

For the "customer went idle" case, you don't detect it after the fact, you catch it live with the Wait block:

Timeout branch: fires when the customer hasn't sent a message within the time you set. That's your idle path (send an SMS, run a survey, disconnect, etc.). Return branch: fires if the customer comes back and sends a message. So the practical setup is: agent ends chat → Disconnect flow starts → Wait block → if the customer never responds, the Timeout branch handles the idle timeout; if they reply, you route from the Return branch. Keep in mind the total chat duration (all Wait blocks combined) caps at 7 days.

If you genuinely need to know who disconnected in real time (for logic outside the flow), that lives in contact events, not the flow. Subscribe to Amazon Connect contact events via EventBridge/Kinesis and read DisconnectReason there, or pull it from the CTR after the contact completes for reporting.