Genesys Cloud - Developer Community!

Hi Team,

I need to disconnect an email interaction if it waits in queue for 10 days without being answered.

In an In-Queue Flow, the Wait action is limited to 72 hours. I tried using the Wait action inside a Loop (multiple iterations) to extend the wait time, but the flow does not reliably reach the Disconnect action.

Questions:

1. Are multi-day waits using Wait + Loop unsupported in In-Queue Flows?

2. Is Queue → Email Auto-Disconnect Timeout the recommended/supported way to handle long email wait times (e.g., 7 days)?

#Architect
#DataActions
#PlatformAPI
#Triggers

------------------------------
Haridass Sarangan
------------------------------

Hi Haridass,

I am kind of doing the same thing.

I am using the recurring state of the in-queue flow to test the Flow.StartDateTimeUtc and determine how long the mail has been in the queue - i.e. DateTimeDiff(GetCurrentDateTimeUtc(), Flow.StartDateTimeUtc).

I believe the wait action pauses the flow processing, so the email won't get answered during the "wait" - which is not what we want.

But your mention of the "Queue → Email Auto-Disconnect Timeout" has made me curious.
I can't see a reference to this in the Genesys docs - can you point me to the documentation for this function?

Cheers

Andrew Watson

------------------------------
Andrew Watson
Architect
------------------------------

Hi,

Currently, there is no action configured in the in-queue flow. The requirement is for the interaction to wait for 10 days and then be disconnected if it is not answered.

I initially assumed that placing a Disconnect block after a Wait block would cause the interaction to remain in the Wait state for 10 days and then execute the Disconnect. However, the maximum wait time allowed is only 72 hours. Even after splitting the wait into multiple Wait blocks, this approach did not work.

Could you please clarify whether there is any default timeout for in-queue email interactions? Specifically, if a flow remains active for more than 3 days, does the system automatically disconnect the interaction or route it to event handling?

In summary, i need to automatically disconnect a waiting interaction after 10 days if it is not answered.

------------------------------
Haridass Sarangan
------------------------------

Original Message:
Sent: 01-21-2026 07:04
From: Andrew Watson
Subject: In-Queue Flow – Long Wait (7 Days) for Email Disconnect

Hi Haridass,

I am kind of doing the same thing.

I am using the recurring state of the in-queue flow to test the Flow.StartDateTimeUtc and determine how long the mail has been in the queue - i.e. DateTimeDiff(GetCurrentDateTimeUtc(), Flow.StartDateTimeUtc).

I believe the wait action pauses the flow processing, so the email won't get answered during the "wait" - which is not what we want.

But your mention of the "Queue → Email Auto-Disconnect Timeout" has made me curious.
I can't see a reference to this in the Genesys docs - can you point me to the documentation for this function?

Cheers

Andrew Watson

------------------------------
Andrew Watson
Architect
------------------------------

Hello @Haridass Sarangan, greetings from Brasil!

You don't necessarily need to use Architect to control how long an email remains in the queue.

This can be handled directly at the queue configuration level by defining a Backup Queue (Queue → Direct). In the primary queue, you can configure the Go To Backup After timer, which determines how long the email interaction can remain enqueued. Once that time threshold is reached without being answered, the interaction is automatically moved to the backup queue.

From there, the backup queue can be used as a controlled handling point. You may associate an In-Queue Email Flow to the backup queue and apply the desired behavior, such as a short wait followed by a disconnect, an automated response, or any other business-specific treatment.

With this approach:

• the long wait logic is handled natively by queue routing, not by extended waits or loops in Architect;

• the primary queue remains focused on normal email handling;

• the backup queue centralizes the exception logic for aged interactions in a supported and predictable way.

This pattern avoids the 72-hour In-Queue Flow limitation and provides a cleaner, more maintainable solution for managing long email wait times.

In this example, the interaction will be routed to the "Apoio BKO Entrega CB" queue, where it will be disconnected by the configured in-queue flow.

Create and configure queues View summary - Genesys Cloud Resource Center

------------------------------
Fernando Sotto dos Santos
Consultor Grupo Casas Bahia
------------------------------

Using backup queue is a good thing if you only need fixed wait time. Then this works fine. If you need more flexible waiting time you transfer it it to a queue with no agent available. On that queue you have an in queue flow that has a loop that check ex every hour to see if Current time is after a datetime you have set as a participant data in the first flow and put into a variable in the waiting queue. 

------------------------------
Eystein Kylland
Systemutvikler Genesys Applikasjonsspesialist
------------------------------

Original Message:
Sent: 01-21-2026 08:25
From: Fernando Sotto dos Santos
Subject: In-Queue Flow – Long Wait (7 Days) for Email Disconnect

Hello @Haridass Sarangan, greetings from Brasil!

You don't necessarily need to use Architect to control how long an email remains in the queue.

This can be handled directly at the queue configuration level by defining a Backup Queue (Queue → Direct). In the primary queue, you can configure the Go To Backup After timer, which determines how long the email interaction can remain enqueued. Once that time threshold is reached without being answered, the interaction is automatically moved to the backup queue.

From there, the backup queue can be used as a controlled handling point. You may associate an In-Queue Email Flow to the backup queue and apply the desired behavior, such as a short wait followed by a disconnect, an automated response, or any other business-specific treatment.

With this approach:

• the long wait logic is handled natively by queue routing, not by extended waits or loops in Architect;

• the primary queue remains focused on normal email handling;

• the backup queue centralizes the exception logic for aged interactions in a supported and predictable way.

This pattern avoids the 72-hour In-Queue Flow limitation and provides a cleaner, more maintainable solution for managing long email wait times.

In this example, the interaction will be routed to the "Apoio BKO Entrega CB" queue, where it will be disconnected by the configured in-queue flow.

Create and configure queues View summary - Genesys Cloud Resource Center

------------------------------
Fernando Sotto dos Santos
Consultor Grupo Casas Bahia
------------------------------

I am not sure why you would like to use a backup queue in this case. If your primary queue is not being processed effectively and conversations remain there for more than 10 days without being answered, you can do the steps Andrew have mentioned. Compare the orginal flow datetime with current datetime and disconnect conversation if it is more than what you want, e.g. 10-days.

Regards

------------------------------
Vineet Kakroo
Senior Technical Consultant
------------------------------

Looks like this question is resolved 😊
When you get a chance, please mark the reply that helped most as the Best Answer. It helps others with the same question!

------------------------------
Fernando Sotto dos Santos
Consultor Grupo Casas Bahia
------------------------------

All...please keep in mind the info in the Resource Center article

In particular the Notes regarding In-Queue Email flows:

Notes:

• For in-queue email and in-queue message flows, the maximum flow duration is 72 hours. After 72 hours, the flow disconnects.
• For email and message flows, Architect limits the number of in-queue flows that open for a particular email or message interaction to 30. This limitation prevents the interaction size from increasing due to the launch of a new flow each time a Transfer to ACD action runs. The problem can occur when the target queue is the current queue.
• If the initial email or message is an outbound interaction, the in-queue flow for the interaction does not launch even if it is set as default on the queue that the message is sent on behalf. The in-queue flow launches only after an inbound response arrives.

I bolded the first Note because, as you see, once the In-Queue flow hits 72 hours it disconnects (not the conversation, just the flow) and thus is no longer in control of the conversation. The conversation will still route if an agent comes available, but you have no control over it via flow after 72 hours.

------------------------------
George Ganahl GCCX-AI, GCP, GCD
Technical Adoption Champion
Genesys
------------------------------

@Haridass Sarangan, volte aqui para nos contar qual foi a sua ação e se as sugestões que demos atendeu a sua necessidade!

------------------------------
Fernando Sotto dos Santos
Consultor Grupo Casas Bahia
------------------------------