Original Message:
Sent: 04-30-2026 08:49
From: Elisson Fernandes
Subject: Email In-queue Flow
Hi,
Sure, here are my answers:
1. Once the email is waiting in queue with an In-Queue Email Flow assigned, the flow keeps running until the interaction is answered, transferred, disconnected, or reaches the maximum flow duration.
Even if the main logic has already executed, the flow continues in the Recurring State behavior.
2. As far as I know, no. If the email remains in queue and the In-Queue Email Flow keeps running, it will eventually reach the 72 hour limit. At that point, the interaction will be disconnected and the flow will end with "Execution time exceeded".
3. For Email In-Queue Flows, I would recommend keeping the flow as simple and intentional as possible.
Best practices would be:
- Use the In-Queue Email Flow only for logic that really needs to happen while the email is waiting in queue.
Example: Escalating the interaction if it has waited too long. - Avoid long or unnecessary processing inside the In-Queue Flow.
- Do not depend on the In-Queue Flow as a long-term holding mechanism, because it has a maximum duration of 72 hours.
Example: if emails can wait several days before being answered, do not rely on an In-Queue Flow just to keep the interaction alive. The flow will eventually reach the 72-hour limit and the interaction will be disconnected. - Be careful with Recurring States, since they continue to run while the interaction is waiting.
Example: if the Recurring State updates participant data or calls Data Actions, make sure the logic has clear conditions. Otherwise, it can execute repeatedly while the email is still waiting in queue. - If the flow can run close to the 72-hour limit, define a clear re-entry or fallback strategy.
Example: before reaching 72 hours, transfer the email back to the same queue or to a fallback queue. If transferring back to the same queue, adjust the priority to compensate for the waiting time reset.
At the moment, we have one Email In-Queue Flow use case where two agents handle interactions in a specific queue. If an interaction remains unanswered for more than 24 hours, it is transferred to another queue with higher priority, where more agents are available to handle it.
------------------------------
Elisson Fernandes
Original Message:
Sent: 04-30-2026 02:54
From: Raluca Radu
Subject: Email In-queue Flow
Hello,
Thank you for your answer. Option 2 is currently implemented.
My question is not about the transfer to the proper queue based on the language, but rather on how the In-queue works.
- We would like to exit the In-queue flow immediately after the code is executed. Unfortunately, this does not seem to be possible, we have to wait 72 hours for the flow to end. The Recurring state runs every X seconds/minutes/hours, even if it is empty. Is there any method to exit the In-Queue for Email when you want/need to?
- After 72 hours, the flow ends in Error, throwing "Execution time exceeded", we see all these errors in the Operational Console. Is there any way to end the In-queue flow without transferring to another queue, just end the flow and wait on the queue, without having the "Execution time exceeded" error?
- What do you know as best practice for the E-mail In-queue flow?
Thank you,
Raluca
------------------------------
Raluca Radu
Original Message:
Sent: 04-29-2026 17:21
From: Elisson Fernandes
Subject: Email In-queue Flow
Hi Raluca,
In-queue email has a maximum duration of 72 hours, which is why the disconnection happens.
As you noticed, even when the flow completes its entire path, it then moves into Recurring States and continues looping until the interaction is either answered or disconnected due to the maximum duration limit.
http://help.genesys.cloud/articles/queue-call-flows/
From my perspective, we have two options:
1. Handle it in the inbound flow (simpler):
Apply the language and priority logic in the inbound flow and transfer directly to the correct queue. This way, you wouldn't need to configure in-queue email at the queue level.
2. Handle it in the In-Queue Flow (more complex):
In the In-Queue Flow, transfer back to the same queue (an interaction can have up to 30 in-queue flows).
The key concern is that the queue wait time resets in this scenario. You would need to adjust the logic to: wait X time, transfer again, and repeat. Also, it would be helpful to assign an appropriate priority on each transfer so the interaction doesn't always go back to the end of the queue.
Option 1 is simpler and more straightforward with minimal impact. Option 2 is something I haven't implemented myself (nor have I seen it implemented), and it will likely have a bigger impact, including on reporting. If you choose this route, I strongly recommend running multiple tests.
------------------------------
Elisson Fernandes
Original Message:
Sent: 04-29-2026 13:32
From: Raluca Radu
Subject: Email In-queue Flow
Hello,
Our customer needs a short In-Queue Flow for emails to calculate priority and redirect to another queue if the Interaction language does not match the queue. After this short code, we have the following questions and issues:
- We would like to exit the In-queue flow immediately after the code is executed. Unfortunately, this does not seem to be possible, we have to wait 72 hours for the flow to end. The Recurring state runs every X seconds/minutes/hours, even if it is empty. Is there any method to exit the In-Queue for Email when you want/need to?
- After 72 hours, the flow ends in Error, throwing "Execution time exceeded", we see all these errors in the Operational Console. Is there any way to end the In-queue flow without transferring to another queue, just end the flow and wait on the queue, without having the "Execution time exceeded" error?
- What do you know as best practice for the E-mail In-queue flow?
Thank you. Kind Regards,
Raluca
#Architect #Digitalchannels #Digital #Email
------------------------------
Raluca Radu
------------------------------