Genesys Cloud - Main

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

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.

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.

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.

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.

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.