Genesys Cloud - Developer Community!

Hi Genesys Developer Community,

I am currently working on a routing scenario in Genesys Cloud and have encountered a challenge regarding direct agent transfers while maintaining After Call Work (ACW) settings, specifically while restricted to Standard Routing.

The Scenario

When a call enters the system and a specific agent is in Available or On-Queue status, I need the call to be routed specifically to that agent. It is mandatory that the transfer respects the ACW options configured for that specific queue.

The Current Issue

I am facing a conflict between manual transfer logic and the ACD engine:

• Current Logic: The call transfers to test_queue. Inside the In-Queue Flow, I use a Transfer to User block to target the specific agent.

• The Conflict: The call is treated as a standard queue interaction first. If any agent is On-Queue, the call alerts them via standard distribution. The Transfer to User block only executes if the agent manually declines that initial alerting.

• Looping Attempt: I tried looping from the In-Queue flow back to an Inbound flow to trigger the transfer, but the system still prioritizes general queue distribution over the specific user block.

Constraints & Requirements

I am aware of Preferred and Direct Routing options; however, for this specific scenario, I must achieve this using Standard Routing only. My requirements are:

1. Immediate Routing: Route to a specific agent immediately without general queue distribution preempting it.

2. ACW Retention: Ensure the call carries the Queue's ACW configuration.

3. Fallback Logic: If the specific agent is unavailable or declines, the call must offer a Voicemail option to that agent; otherwise, it should route to the next available agent.

4. In-Queue Experience: The standard In-Queue logic/prompts must still play during the process.

Seeking Suggestions

Has anyone successfully "pinned" a call to a specific user using Architect variables or specific Transfer to ACD properties within a Standard Routing environment?

I am looking for a way to prioritize the specific agent assignment without the ACD engine treating it as a generic "next available agent" request.

Any insights or creative workarounds would be greatly appreciated.

#Architect
#DataActions
#Uncategorized

------------------------------
Thanks,
Balaji B
------------------------------

Hi Balaji,

Under Standard Routing, I don’t believe it’s possible to truly “pin” a call to a specific user using Architect variables or Transfer to ACD properties. Once the interaction is transferred to ACD, the routing engine immediately evaluates all eligible agents and distributes based on the queue’s routing method.

One possible approach while staying within Standard Routing would be to control eligibility instead of trying to override distribution. For example, create a unique skill for that specific agent and require that skill in the initial Transfer to ACD. Since only that agent has the skill, the interaction would route to them first while still preserving the queue’s ACW and in-queue experience.

If the agent does not answer, you could then handle voicemail or fallback logic within the In-Queue flow.

Happy to hear if anyone has implemented this differently.

Hi Phaneendra,

Thanks for your suggestions and workaround solutions.

I appreciate the insight regarding skill-based eligibility, but in this case, we are using non-skill routing. Additionally, the agents are not static; they are dynamically configured at a Data Table level, so we aren't targeting just one fixed individual across the board.

I actually tried a workaround using dummy queues that seems to be working, but I have concerns about the impact. Here is what I did:

• I route the call to a dummy queue.

• Inside that dummy queue's In-Queue Flow, I execute a Transfer to User block directed at the specific agent fetched from my Data Table.

While this achieves the direct transfer, it likely affects reporting accuracy, as the interaction is technically touching multiple queues before reaching the agent.

I am still open to new insights and workaround solutions that might achieve this more cleanly within Standard Routing without compromising the reporting data.

------------------------------
Thanks,
Balaji B
------------------------------

Original Message:
Sent: 02-27-2026 07:27
From: Phaneendra Avatapalli
Subject: Technical Query: Achieving Direct Agent Transfer with ACW using Standard Routing

Hi Balaji,

Under Standard Routing, I don't believe it's possible to truly "pin" a call to a specific user using Architect variables or Transfer to ACD properties. Once the interaction is transferred to ACD, the routing engine immediately evaluates all eligible agents and distributes based on the queue's routing method.

One possible approach while staying within Standard Routing would be to control eligibility instead of trying to override distribution. For example, create a unique skill for that specific agent and require that skill in the initial Transfer to ACD. Since only that agent has the skill, the interaction would route to them first while still preserving the queue's ACW and in-queue experience.

If the agent does not answer, you could then handle voicemail or fallback logic within the In-Queue flow.

Happy to hear if anyone has implemented this differently.

Hi Balaji,

Thanks for the detailed explanation and for sharing your workaround that's really helpful context.

I'm also interested to see if anyone else in the community has implemented this differently without affecting reporting.

------------------------------
Phaneendra
Technical Solutions Consultant
Monash University
Australia
------------------------------

Original Message:
Sent: 02-27-2026 08:13
From: Balaji Balakrishnan
Subject: Technical Query: Achieving Direct Agent Transfer with ACW using Standard Routing

Hi Phaneendra,

Thanks for your suggestions and workaround solutions.

I appreciate the insight regarding skill-based eligibility, but in this case, we are using non-skill routing. Additionally, the agents are not static; they are dynamically configured at a Data Table level, so we aren't targeting just one fixed individual across the board.

I actually tried a workaround using dummy queues that seems to be working, but I have concerns about the impact. Here is what I did:

• I route the call to a dummy queue.

• Inside that dummy queue's In-Queue Flow, I execute a Transfer to User block directed at the specific agent fetched from my Data Table.

While this achieves the direct transfer, it likely affects reporting accuracy, as the interaction is technically touching multiple queues before reaching the agent.

I am still open to new insights and workaround solutions that might achieve this more cleanly within Standard Routing without compromising the reporting data.

------------------------------
Thanks,
Balaji B

Original Message:
Sent: 02-27-2026 07:27
From: Phaneendra Avatapalli
Subject: Technical Query: Achieving Direct Agent Transfer with ACW using Standard Routing

Hi Balaji,

Under Standard Routing, I don't believe it's possible to truly "pin" a call to a specific user using Architect variables or Transfer to ACD properties. Once the interaction is transferred to ACD, the routing engine immediately evaluates all eligible agents and distributes based on the queue's routing method.

One possible approach while staying within Standard Routing would be to control eligibility instead of trying to override distribution. For example, create a unique skill for that specific agent and require that skill in the initial Transfer to ACD. Since only that agent has the skill, the interaction would route to them first while still preserving the queue's ACW and in-queue experience.

If the agent does not answer, you could then handle voicemail or fallback logic within the In-Queue flow.

Happy to hear if anyone has implemented this differently.