Dynamics Community Forum Thread Details

Delay in voice overflow transfer to next queue

Hi all,

We’re seeing unexpected behavior with Queue Overflow handling for voice work items.
We have a queue overflow configured to trigger after 60 seconds, but in practice it often takes close to 3 minutes before an unanswered voice call is transferred to the next queue.
The documentation mentions that overflow handling can occur in batches, but we’re seeing this even when there’s only one active call in the queue. It feels like a background evaluation/scheduled process has to “pick up” the record before the transfer actually happens.

If this is expected behavior:

Is there any way to speed up the overflow evaluation/processing cycle?
Are there any settings or best practices to reduce the delay?

What are your experiences with how long a voice call actually takes to overflow/transfer to another queue compared to the configured threshold?

Thanks in advance!

Categories:

Dynamics 365 Contact Center

1. When a call hits your queue, it doesn't just sit and wait for the overflow timer. It goes through a series of "sweeps."

Assignment Attempt (0–60s): The system first tries to find an available agent. Even if no one is available, the routing engine often completes its first "assignment cycle" before it acknowledges that the item is eligible for overflow.
The Evaluation Sweep (The "Batch" Issue): Unified Routing is an asynchronous service. It evaluates overflow conditions in cycles (typically every 30 to 60 seconds). If your 60-second timer expires just after a sweep has finished, the call sits for another full cycle before the engine "notices" it’s ready to move.
The Handshake (Voice Specific): For Voice, the system has to signal Azure Communication Services (ACS) to re-route the media stream. This adds a few extra seconds of overhead compared to a text-based chat.

2. Why it feels like 3 minutes
If your overflow is set to 60 seconds, the math usually looks like this:

60s: Initial wait (as configured).
+ 30-60s: Waiting for the next "Evaluation Sweep" to trigger.
+ 30s: Latency in the "Transfer to Queue" action and finding an agent in the next queue. Total: ~150–180 seconds.

3. While you can't change the background "sweep" frequency (that's managed by Microsoft), you can optimize your configuration to reduce the total "dead air" time.
A. Lower the Threshold (The "Buffer" Strategy)
If you strictly need the call to move at the 2-minute mark, set your overflow timer to 30 or 40 seconds. This accounts for the ~60-second "sweep latency" and ensures the call is "ready and waiting" when the orchestrator runs its next check.
B. Use "Workstream" Overflow vs. "Queue" Overflow

Queue Overflow: Evaluates after the call has been sitting in a specific queue.
Workstream Overflow: You can set rules at the workstream level for "Long wait time." Sometimes, workstream-level actions are picked up slightly faster because they bypass certain queue-specific assignment logic.

C. Check "Assignment" vs "Overflow"
Ensure you don't have a long Assignment Timeout (how long a call rings an agent before moving to the next) that is conflicting with your Overflow timer. If an agent's "notification" is set to 30 seconds, and they miss it, the system spends time "recycling" that work item before the overflow logic even looks at it.
4. In most enterprise implementations, we see a consistent 45–90 second delay over whatever is configured in the UI.

For critical Voice calls: We often recommend using Direct Routing logic or Azure Function hooks if you need millisecond-precise routing, but that is a significant development lift.
The "Human" Fix: Ensure your "Hold Music" or "Wait Greeting" is long enough to cover the 3-minute gap so the caller doesn't think the line has gone dead during the "Evaluation Sweep."

if this helps pls mark as verified so that it may be helpful for someone else. Thanks!

Quick Links

Leaderboard > Service | Customer Service, Contact Center, Field Service, Guides