Genesys Cloud - Main

We are currently using a Data Action–based solution to create Preferred Agent Callbacks. This configuration ensures that when a callback is generated, it is routed exclusively to the customer's designated preferred agent. To achieve this, the callback is initially placed into the "Direct CM" queue, which contains only the preferred agents.
Our requirement is as follows:
If the callback remains unassigned or unanswered for 2 hours, we want the system to automatically reroute or overflow the same callback to a different queue, "Direct Claims", so that any available agent can handle it.
At the moment, we are not seeing a way to automatically move or reassign the callback to the secondary queue after the 2‑hour threshold. We would like guidance from Genesys on the best practice or recommended approach to achieve this behavior-whether through configuration, a workflow/architect design, a Data Action, or any native callback management feature within Genesys Cloud.

Hi Rawat,

Just checking are you currently using an In-Queue Flow on the "Direct CM" queue for these callbacks?

Since callbacks are treated as active interactions while waiting, an In-Queue Flow can be used to monitor how long they've been in queue and then trigger a transfer (e.g. after 2 hours) to your secondary queue.

Keen to understand your current setup as well.

We are currently using a Data Action–based solution to create Preferred Agent Callbacks. This configuration ensures that when a callback is generated, it is routed exclusively to the customer's designated preferred agent. To achieve this, the callback is initially placed into the "Direct CM" queue, which contains only the preferred agents.
Our requirement is as follows:
If the callback remains unassigned or unanswered for 2 hours, we want the system to automatically reroute or overflow the same callback to a different queue, "Direct Claims", so that any available agent can handle it.
At the moment, we are not seeing a way to automatically move or reassign the callback to the secondary queue after the 2‑hour threshold. We would like guidance from Genesys on the best practice or recommended approach to achieve this behavior-whether through configuration, a workflow/architect design, a Data Action, or any native callback management feature within Genesys Cloud.

Hi Rawat,

You could try the below in your In-Queue Flow, assuming you are storing the callback's queue entry time in something like Task.WaitEntryTime:

DateTimeDiff(GetCurrentDateTimeUtc(), Task.WaitEntryTime) >= MakeDuration(0, 0, ToInt(Task.maxQueueTime), 0)

Task.maxQueueTime could be your threshold value for example, 120 for 2 hours. Once this evaluates to true, you could then transfer the callback to the secondary queue.

Hope this helps.

Hi Phaneendra,

Thank you very much for your response - I truly appreciate your support.

I attempted the method you suggested, but I am facing a few challenges. I also consulted Copilot, and although it initially indicated that the approach should be possible, I continued to receive errors while following the same steps. Ultimately, it stated that In-Queue Architect Flows do not support any DateTime functions, which seems to be the cause of the issue.
Since the expression you provided results in errors each time I try to use it, could you please advise if there is an alternative method to achieve this?

Thank you in advance for your guidance.

------------------------------
Rawat Radhika

Original Message:
Sent: 04-02-2026 09:23
From: Phaneendra Avatapalli
Subject: Preferred Agent Callback Reassignment After Timeout

Hi Rawat,

You could try the below in your In-Queue Flow, assuming you are storing the callback's queue entry time in something like Task.WaitEntryTime:

DateTimeDiff(GetCurrentDateTimeUtc(), Task.WaitEntryTime) >= MakeDuration(0, 0, ToInt(Task.maxQueueTime), 0)

Task.maxQueueTime could be your threshold value for example, 120 for 2 hours. Once this evaluates to true, you could then transfer the callback to the secondary queue.

Hope this helps.

Hi Rawat,

The way we usually do it in our In-Queue Flow when we need the current time is to use an Update Data action and store it in a task variable, for example:

Task.WaitEntryTime = GetCurrentDateTimeUtc()

Then use that stored value later in the comparison logic I gave becomes below

DateTimeDiff(GetCurrentDateTimeUtc(), Task.WaitEntryTime) >= MakeDuration(0, 0, 120, 0)

What each part does:

• GetCurrentDateTimeUtc() = gets the current UTC date/time
• Task.WaitEntryTime = the stored time from when the interaction entered that part of the flow
• DateTimeDiff(...) = calculates the elapsed time between now and the stored time
• MakeDuration(0, 0, 120, 0) = creates a duration of 120 minutes
  (day, hour, minute, second)
• >= = checks whether the elapsed time is greater than or equal to that threshold

I have not tried this solution myself for your exact callback scenario, but it may be worth testing.

If that still does not work, then another way is to use Trigger + Workflow (not tested) may be another direction to look at for a longer timeout scenario. From what I could see, there does not appear to be a dedicated callback-created trigger in the official trigger list, but you could try available conversation topics such as v2.detail.events.conversation.{id}.outbound, v2.detail.events.conversation.{id}.user.start or v2.detail.events.conversation.{id}.acd.end with the right conditions/filters. I would validate the payload fields/values in the trigger schema first to confirm whether the callback timeout case shows up there with the fields you need.

Links:

• https://help.genesys.cloud/articles/overview-of-triggers/
• https://community.genesys.com/discussion/triggering-workflow-for-callback-outbound-call

Hope this helps. Hopefully someone from the community who has implemented this exact pattern can add more detail.

------------------------------
Phaneendra
Technical Solutions Consultant

Original Message:
Sent: 04-07-2026 02:26
From: Rawat Radhika
Subject: Preferred Agent Callback Reassignment After Timeout

Hi Phaneendra,

Thank you very much for your response - I truly appreciate your support.

I attempted the method you suggested, but I am facing a few challenges. I also consulted Copilot, and although it initially indicated that the approach should be possible, I continued to receive errors while following the same steps. Ultimately, it stated that In-Queue Architect Flows do not support any DateTime functions, which seems to be the cause of the issue.
Since the expression you provided results in errors each time I try to use it, could you please advise if there is an alternative method to achieve this?

Thank you in advance for your guidance.

------------------------------
Rawat Radhika

Original Message:
Sent: 04-02-2026 09:23
From: Phaneendra Avatapalli
Subject: Preferred Agent Callback Reassignment After Timeout

Hi Rawat,

You could try the below in your In-Queue Flow, assuming you are storing the callback's queue entry time in something like Task.WaitEntryTime:

DateTimeDiff(GetCurrentDateTimeUtc(), Task.WaitEntryTime) >= MakeDuration(0, 0, ToInt(Task.maxQueueTime), 0)

Task.maxQueueTime could be your threshold value for example, 120 for 2 hours. Once this evaluates to true, you could then transfer the callback to the secondary queue.

Hope this helps.