Just started building flows in Architect and I am struggling with bullseye routing behavior that does not match what I expected from the documentation.
Setup: We have a Transfer to ACD action with bullseye routing configured. Ring 1 targets agents with Spanish language skill at proficiency >= 4. Ring 2 expands to proficiency >= 2. Ring 3 drops the language requirement entirely. Each ring has a 30-second timeout.
Expected behavior: Call waits 30 seconds for Ring 1 agents, if none available it expands to Ring 2 for 30 seconds, then Ring 3.
Actual behavior: The call sits in Ring 1 for 30 seconds, then the entire Transfer to ACD action times out and the flow drops to the timeout path. It never expands to Ring 2 or Ring 3.
I have confirmed there are agents available in Ring 2 and Ring 3 (I can see them in the Available status with the correct skills). The Transfer to ACD action’s overall timeout is set to 120 seconds, which should be enough for all three rings.
What am I missing about how bullseye expansion actually works?
Welcome to what I consider the single most confusing configuration surface in all of Genesys Cloud. This trips up almost everyone the first time.
The issue is that the ring timeout and the Transfer to ACD timeout are two completely separate timers, and the ring timeout behavior depends on WHERE you configured it.
There are two places to set bullseye rings:
- On the Queue definition (Admin > Contact Center > Queues > Bullseye Routing tab)
- On the Transfer to ACD action in Architect (the action’s own bullseye settings)
If you configured the rings on the Transfer to ACD action but the Queue itself has bullseye routing disabled or set to a single ring, the Queue-level configuration takes precedence for the expansion logic. The Transfer to ACD action’s bullseye settings only override the Queue settings if the Queue has “Allow Flow to Override” enabled.
Go to Admin > Contact Center > Queues > [Your Queue] > Bullseye Routing tab and check two things:
- Verify the rings are defined here, not just in the Architect action
- If you want the Architect action to control the rings, enable “Allow Architect Flow to Override Bullseye Routing”
This toggle was added in a 2024 update and defaults to OFF, which means Queue-level settings always win regardless of what you configure in the flow.
The Queue vs Flow override issue is almost certainly the problem. Going through this exact pain right now on our PureConnect migration because PureConnect did not have this dual-configuration concept.
One additional thing that causes rings to not expand even when configured correctly: if ALL agents in the org who have the target skill are currently in a non-routable status (like On Queue but in ACW, or in a non-ACD status), the bullseye evaluation short-circuits. The system determines that no agent could possibly answer even with expanded rings, so it goes directly to the timeout path instead of waiting through each ring.
To verify this is not your issue, check the queue’s estimated wait time via the API while a test call is in queue:
GET /api/v2/routing/queues/{queueId}/estimatedwaittime
If the response returns estimatedWaitTimeSeconds: -1, it means the system has determined no agent is available in any ring, and expansion will not occur.
I am also new to GC and had this same problem during our load testing. One more thing I found: if you are testing with only 2-3 agents, make sure they are not all in the same ACD group.
Bullseye ring expansion evaluates skill proficiency across all agents assigned to the queue, but if an agent is assigned to the queue through a Group membership and that Group has a utilization override, the ring evaluation uses the Group utilization settings instead of the org defaults. An agent who appears “Available” in the UI might actually be at maximum utilization from the routing engine perspective.
This was very confusing during our load test because the wallboard showed 3 available agents but the routing engine treated them as fully utilized.