Genesys Cloud - Main

An issue we experience when transferring interactions (predominantly voice) between queues is that the required skills and priority of the target queue are not applied to the transferred interaction. Instead, the original routing context is retained.

I've tested the following approach, which appears to work reliably:

Scenario:
A call is routed to Queue 1 and needs to be transferred to Queue 2, whilst adopting the skills and priority associated with Queue 2.

Solution design:
Create a dedicated transit queue - e.g. "XFER – Queue 2".

• This queue has:

  • No agents assigned

  • An In-Queue Flow configured

• The In-Queue Flow contains a single action:

  • Transfer to ACD → Queue 2

  • With skills and priority explicitly set

Flow:
Call → Queue 1 → Agent Transfer → XFER – Queue 2 → In-Queue Flow → Queue 2 (with correct skills/priority)

Because there are no agents assigned to the XFER queue, the interaction immediately enters a waiting state and the In-Queue Flow executes, effectively re-submitting the interaction into ACD with the desired routing attributes.

This seems to provide a simple, Architect-native way to "re-stamp" interactions during transfer.

Questions:

• Is anyone else using a similar pattern?

• Are there any known drawbacks to this approach (e.g. reporting, edge cases, routing delays)?

• Are there alternative methods to achieve this without introducing a transit queue?

Appreciate any feedback or thoughts.

#ArchitectandDesign

------------------------------
Matthew Tipler
------------------------------

Hi Matthew,

We are not currently using this approach, but I would add the following:

Have you considered transferring to a Flow instead of directly to a queue?

From there, you could use a Transfer to ACD action within the flow to apply the required skills and priority before routing to the target queue. This could help achieve a similar outcome without introducing a transit queue, although it would require agents to transfer to flows instead of queues.

Another option could be using a custom script with an API call to update the interaction’s routing attributes before the transfer (for example, using PATCH /api/v2/conversations/{conversationId}/participants/{participantId}). We are not using this approach today, but it could avoid the need for a transit queue or flow, with the trade-off of additional development effort and changes to how agents initiate transfers.

Hope others in the community might have different approaches as well.

Regards,

Phaneendra

Hi Phaneendra,

Thank you for your response!

Transferring to a flow would have been my first choice although I don't believe that is possible?

Many thanks.

------------------------------
Matthew Tipler
------------------------------

Original Message:
Sent: 03-19-2026 07:43
From: Phaneendra Avatapalli
Subject: Transferred Interactions > Skill / Priority

Hi Matthew,

We are not currently using this approach, but I would add the following:

Have you considered transferring to a Flow instead of directly to a queue?

From there, you could use a Transfer to ACD action within the flow to apply the required skills and priority before routing to the target queue. This could help achieve a similar outcome without introducing a transit queue, although it would require agents to transfer to flows instead of queues.

Another option could be using a custom script with an API call to update the interaction's routing attributes before the transfer (for example, using PATCH /api/v2/conversations/{conversationId}/participants/{participantId}). We are not using this approach today, but it could avoid the need for a transit queue or flow, with the trade-off of additional development effort and changes to how agents initiate transfers.

Hope others in the community might have different approaches as well.

Regards,

Phaneendra

Hi Matthew, 

Your transit queue process is good and other customers use similar approaches for this behaviour.

The Issue you have is that transferred calls retain original skills/priority instead of adopting target queue attributes, this is confirmed platform behaviour.

Your Solution itself should work well, the empty transit queue with in-queue flow effectively re-stamps the interaction.

Reporting would shows extra queue hops and you'll need to maintain transit queues for each destination.

Alternatives:

• "Strip Skills on Blind Transfer" org setting (only removes skills, doesn't add new ones)
• Transfer to flow instead of queue (similar result to your approach as @Phaneendra Avatapalli has commented on)
• Script Buttons - You could develop a script which acts as the transfer mechanism to the target queue with the desired parameters via custom actions
• External Contact - Transfer to external DID that routes back through inbound flow with new skills/priority

Your method is a good approach, use clear naming like "XFER-QueueName" and document for reporting teams.

------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------

Thank you, guys. Really appreciate the input. 

RE transferring interactions to flows - it's possible that I'm being a little 'daft' here but I can only see the option to transfer to agents (user), queue or external contact. 

------------------------------
Matthew Tipler
------------------------------

Original Message:
Sent: 03-19-2026 08:14
From: Josh Coyle
Subject: Transferred Interactions > Skill / Priority

Hi Matthew, 

Your transit queue process is good and other customers use similar approaches for this behaviour.

The Issue you have is that transferred calls retain original skills/priority instead of adopting target queue attributes, this is confirmed platform behaviour.

Your Solution itself should work well, the empty transit queue with in-queue flow effectively re-stamps the interaction.

Reporting would shows extra queue hops and you'll need to maintain transit queues for each destination.

Alternatives:

• "Strip Skills on Blind Transfer" org setting (only removes skills, doesn't add new ones)
• Transfer to flow instead of queue (similar result to your approach as @Phaneendra Avatapalli has commented on)
• Script Buttons - You could develop a script which acts as the transfer mechanism to the target queue with the desired parameters via custom actions
• External Contact - Transfer to external DID that routes back through inbound flow with new skills/priority

Your method is a good approach, use clear naming like "XFER-QueueName" and document for reporting teams.

------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------

In GC you can call or transfer to a flow by using  flowname@localhost  as phone number.
You could configure an external contact pointing to your flow using this format. Drawback is that  the name of the flow is visible to the agent, using a fake DNIS which has a call-routing to your flow might be better.
You could also use flowname@localhost as target for a transfer action in a script. The script could pass additional participant data which could be used in the flow, for example a key for lookup in a data-table where you define target-queue, schedule-group to check and so on.

------------------------------
Christian Karpp
Principal PS Consultant
------------------------------

Original Message:
Sent: 03-19-2026 08:23
From: Matthew Tipler
Subject: Transferred Interactions > Skill / Priority

Thank you, guys. Really appreciate the input. 

RE transferring interactions to flows - it's possible that I'm being a little 'daft' here but I can only see the option to transfer to agents (user), queue or external contact. 

------------------------------
Matthew Tipler
------------------------------


Original Message:
Sent: 03-19-2026 08:14
From: Josh Coyle
Subject: Transferred Interactions > Skill / Priority

Hi Matthew, 

Your transit queue process is good and other customers use similar approaches for this behaviour.

The Issue you have is that transferred calls retain original skills/priority instead of adopting target queue attributes, this is confirmed platform behaviour.

Your Solution itself should work well, the empty transit queue with in-queue flow effectively re-stamps the interaction.

Reporting would shows extra queue hops and you'll need to maintain transit queues for each destination.

Alternatives:

• "Strip Skills on Blind Transfer" org setting (only removes skills, doesn't add new ones)
• Transfer to flow instead of queue (similar result to your approach as @Phaneendra Avatapalli has commented on)
• Script Buttons - You could develop a script which acts as the transfer mechanism to the target queue with the desired parameters via custom actions
• External Contact - Transfer to external DID that routes back through inbound flow with new skills/priority

Your method is a good approach, use clear naming like "XFER-QueueName" and document for reporting teams.

------------------------------
Josh Coyle
Senior Professional Services Consultant

Thank you Josh for the detailed breakdown and providing more alternatives helpful as always 👍

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

Original Message:
Sent: 03-19-2026 08:14
From: Josh Coyle
Subject: Transferred Interactions > Skill / Priority

Hi Matthew, 

Your transit queue process is good and other customers use similar approaches for this behaviour.

The Issue you have is that transferred calls retain original skills/priority instead of adopting target queue attributes, this is confirmed platform behaviour.

Your Solution itself should work well, the empty transit queue with in-queue flow effectively re-stamps the interaction.

Reporting would shows extra queue hops and you'll need to maintain transit queues for each destination.

Alternatives:

• "Strip Skills on Blind Transfer" org setting (only removes skills, doesn't add new ones)
• Transfer to flow instead of queue (similar result to your approach as @Phaneendra Avatapalli has commented on)
• Script Buttons - You could develop a script which acts as the transfer mechanism to the target queue with the desired parameters via custom actions
• External Contact - Transfer to external DID that routes back through inbound flow with new skills/priority

Your method is a good approach, use clear naming like "XFER-QueueName" and document for reporting teams.

------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------