Genesys Cloud - Main

When last nights (5-7-2026) AWS Americas US-East issue occurred, we had calls stacking up in our Emergency queue even though we had 15 agents On-Queue in Idle.  We made the switch to our West DR environment and made the necessary changes to our AT&T Rout It plan to route calls to West.  That took care of any new calls coming in, however we had 20-30 Emergency calls still Waiting in our Production Emergency queue.

It seems like the only option was to Disconnect them and hope they call back to be routed to West.  Is that really the only option (Disconnect and cross your fingers)?  Is there not a way to redirect the call to either a prompt with a message to hang up and call back or better yet to another flow that would dial the Emergency line again, which would then send them to our DR environment?

We've also had need for this in the past when a holiday was not set correctly and before we caught it, there were calls in queue that we could do nothing with except disconnect them (our mistake admittedly, but would be nice to be able to point those to a prompt and then disconnect).

Any thoughts or feedback welcome.  Thank you!

Great question, and honestly, something worth having a plan for before the next incident hits. Disconnecting and crossing your fingers isn't the only option, but the setup needs to be in place ahead of time.

The key thing to understand is that swapping which in-queue flow is assigned to your queue mid-incident will not help the calls already sitting there. Those calls are already executing whatever flow they entered on. However, if you go into Architect and modify and republish the actual in-queue flow itself, calls already in queue can pick up that updated logic on their next recurring state cycle.

So if your flow is built with a recurring state that loops every 30 seconds, you can republish with either a Transfer to ACD pointing to a different queue or a play prompt, then disconnect, and those waiting calls will hit that new logic on their next loop. That is your real lever during an outage.

You can also use Transfer to ACD inside an in-queue flow to point waiting calls to a completely different queue, so if your DR environment had a queue set up and staffed, you could redirect through the flow itself without any manual intervention.

The move is to build your Emergency in-queue flow now with DR scenarios already baked in, whether that is a prompt telling callers to hang up and dial your DR number or a straight transfer to a backup queue. That way, when something like the AWS issue hits again, you are republishing a flow you already built and tested, not building one on fire. 😅

When last nights (5-7-2026) AWS Americas US-East issue occurred, we had calls stacking up in our Emergency queue even though we had 15 agents On-Queue in Idle.  We made the switch to our West DR environment and made the necessary changes to our AT&T Rout It plan to route calls to West.  That took care of any new calls coming in, however we had 20-30 Emergency calls still Waiting in our Production Emergency queue.

It seems like the only option was to Disconnect them and hope they call back to be routed to West.  Is that really the only option (Disconnect and cross your fingers)?  Is there not a way to redirect the call to either a prompt with a message to hang up and call back or better yet to another flow that would dial the Emergency line again, which would then send them to our DR environment?

We've also had need for this in the past when a holiday was not set correctly and before we caught it, there were calls in queue that we could do nothing with except disconnect them (our mistake admittedly, but would be nice to be able to point those to a prompt and then disconnect).

Any thoughts or feedback welcome.  Thank you!

Edit: Hey @Kaio Oliveira ,  totally fair to question it, so I actually built and tested it live. Here is exactly what I did and what happened.

I built a DR_Queue_Control data table in Genesys Cloud with three columns, DR_Status, DR_Message, and DR_QueueName, and one row keyed to EMERGENCY. The in-queue flow does a Data Table Lookup on every recurring state cycle and branches based on whatever DR_Status is set to at that moment.

The Architect flow handles three scenarios natively. Normal just plays hold music and loops. Message plays a dynamic TTS message pulled straight from the data table, then disconnects cleanly. Transfer does a Find Queue lookup and Transfer to ACD to route the caller to a DR queue without them ever hearing a message.

I then called into the queue, let the call sit in the queue holding, and while it was already waiting, I went into the data table and changed DR_Status from Normal to Message. No Architect republish, no touching the flow, just one field change in a data table. The call was live in the queue the entire time, as you can see here.

The message played on the very next recurring state cycle. The caller never got disconnected unexpectedly, and no one had to touch the Architect during the incident. Tested and confirmed working. 💪

@Matt Tucker tagging you, as you can use this as an example for a long-term solution if that issue ever arises again. Fingers crossed, it doesn't happen any time soon. 

Hi Chris 

Edit: Hey @Kaio Oliveira ,  totally fair to question it, so I actually built and tested it live. Here is exactly what I did and what happened.

I built a DR_Queue_Control data table in Genesys Cloud with three columns, DR_Status, DR_Message, and DR_QueueName, and one row keyed to EMERGENCY. The in-queue flow does a Data Table Lookup on every recurring state cycle and branches based on whatever DR_Status is set to at that moment.

The Architect flow handles three scenarios natively. Normal just plays hold music and loops. Message plays a dynamic TTS message pulled straight from the data table, then disconnects cleanly. Transfer does a Find Queue lookup and Transfer to ACD to route the caller to a DR queue without them ever hearing a message.

I then called into the queue, let the call sit in the queue holding, and while it was already waiting, I went into the data table and changed DR_Status from Normal to Message. No Architect republish, no touching the flow, just one field change in a data table. The call was live in the queue the entire time, as you can see here.

The message played on the very next recurring state cycle. The caller never got disconnected unexpectedly, and no one had to touch the Architect during the incident. Tested and confirmed working. 💪

@Matt Tucker tagging you, as you can use this as an example for a long-term solution if that issue ever arises again. Fingers crossed, it doesn't happen any time soon. 

When last nights (5-7-2026) AWS Americas US-East issue occurred, we had calls stacking up in our Emergency queue even though we had 15 agents On-Queue in Idle.  We made the switch to our West DR environment and made the necessary changes to our AT&T Rout It plan to route calls to West.  That took care of any new calls coming in, however we had 20-30 Emergency calls still Waiting in our Production Emergency queue.

It seems like the only option was to Disconnect them and hope they call back to be routed to West.  Is that really the only option (Disconnect and cross your fingers)?  Is there not a way to redirect the call to either a prompt with a message to hang up and call back or better yet to another flow that would dial the Emergency line again, which would then send them to our DR environment?

We've also had need for this in the past when a holiday was not set correctly and before we caught it, there were calls in queue that we could do nothing with except disconnect them (our mistake admittedly, but would be nice to be able to point those to a prompt and then disconnect).

Any thoughts or feedback welcome.  Thank you!

#Routing(ACD/IVR)

------------------------------
Matt Tucker
IT
------------------------------

Hello @Matt Tucker

One way to work in this situation is to configure a data table in your In  Queue flow for emergency messages. In this way, you can inform the customer and decide if you should disconnect them or not.

Each step the flow will validate:

Until finally found active:

It's a simple structure, you can adjust or inprove in your way.

------------------------------
Arthur Pereira Reinoldes

Original Message:
Sent: 05-08-2026 15:35
From: Matt Tucker
Subject: Calls stuck Waiting in Queue

When last nights (5-7-2026) AWS Americas US-East issue occurred, we had calls stacking up in our Emergency queue even though we had 15 agents On-Queue in Idle.  We made the switch to our West DR environment and made the necessary changes to our AT&T Rout It plan to route calls to West.  That took care of any new calls coming in, however we had 20-30 Emergency calls still Waiting in our Production Emergency queue.

It seems like the only option was to Disconnect them and hope they call back to be routed to West.  Is that really the only option (Disconnect and cross your fingers)?  Is there not a way to redirect the call to either a prompt with a message to hang up and call back or better yet to another flow that would dial the Emergency line again, which would then send them to our DR environment?

We've also had need for this in the past when a holiday was not set correctly and before we caught it, there were calls in queue that we could do nothing with except disconnect them (our mistake admittedly, but would be nice to be able to point those to a prompt and then disconnect).

Any thoughts or feedback welcome.  Thank you!

#Routing(ACD/IVR)

------------------------------
Matt Tucker
IT
------------------------------

Great visual breakdown @Arthur Pereira Reinoldes This is exactly where we landed too. We started with the republish approach first to catch calls already in queue, then evolved to the data table flag so we could skip the republish step entirely during an active incident. Having both in your toolkit is the move honestly, republish for flow logic changes, data table for real time flag flipping without touching Architect at all.

Hello @Matt Tucker

One way to work in this situation is to configure a data table in your In  Queue flow for emergency messages. In this way, you can inform the customer and decide if you should disconnect them or not.

Each step the flow will validate:

Until finally found active:

It's a simple structure, you can adjust or inprove in your way.

------------------------------
Arthur Pereira Reinoldes

Original Message:
Sent: 05-08-2026 15:35
From: Matt Tucker
Subject: Calls stuck Waiting in Queue

When last nights (5-7-2026) AWS Americas US-East issue occurred, we had calls stacking up in our Emergency queue even though we had 15 agents On-Queue in Idle.  We made the switch to our West DR environment and made the necessary changes to our AT&T Rout It plan to route calls to West.  That took care of any new calls coming in, however we had 20-30 Emergency calls still Waiting in our Production Emergency queue.

It seems like the only option was to Disconnect them and hope they call back to be routed to West.  Is that really the only option (Disconnect and cross your fingers)?  Is there not a way to redirect the call to either a prompt with a message to hang up and call back or better yet to another flow that would dial the Emergency line again, which would then send them to our DR environment?

We've also had need for this in the past when a holiday was not set correctly and before we caught it, there were calls in queue that we could do nothing with except disconnect them (our mistake admittedly, but would be nice to be able to point those to a prompt and then disconnect).

Any thoughts or feedback welcome.  Thank you!

#Routing(ACD/IVR)

------------------------------
Matt Tucker
IT
------------------------------