Genesys Cloud - Main

If an agent from Group 1 initiates a transfer to Group 2.  Because this is a direct transfer to a queue, none of the call treatments set forth in the Call Flow are being followed.  I am assuming this is correct behavior because the call doesn't go through the actual call flow.  Am I thinking about this correctly?

John,

There won't be an inbound call flow triggered, but the in-queue call flow should be. This is used by many folks to work around this issue including having "dummy" queues to transfer to, perform the treatment and then transfer to the "real" one. Another method is to have a dummy DNIS attached to an inbound call flow (which does the work) and the create an external contact for that DNIS so agents can do the transfer easily.

There are ideas out there (for example, this one) that would also solve this problem for you - I suggest you taker a look and comment / vote if you agree!

HTH

If an agent from Group 1 initiates a transfer to Group 2.  Because this is a direct transfer to a queue, none of the call treatments set forth in the Call Flow are being followed.  I am assuming this is correct behavior because the call doesn't go through the actual call flow.  Am I thinking about this correctly?

Hi John/Paul, this is an interest topic and already submitted my vote to the idea Paul provided, I believe, ultimately the solution is for Genesys to allow transfers to a flow.

Paul, I tried both work arounds you mentioned, and unfortunately those didn't work for us.  The issue with the "dummy" queue idea is that agents will lose visibility of how many agents are on that queue, and how many are idle before initiating the transfer.  For the dummy DNIS, issue is that those DNIS can be leaked to real customers and be used from the outside, possibly creating problems, especially if the queue you are trying to transfer to is an internal queue not meant to be called from the outside.

The work around I ended up implementing is this, and please stay with me here because it might be confusing to explain.  The work around I used was to replicate most of the treatments on the in-queue call flow, the problem with this, is that is not that simple, reason is, if you do a transfer to a queue, if an agent is idle, the call will be delivered and connect right away, without performing any treatments on the in-queue call flow.  So, to work around this and ensure the treatments are played, I had to turn-on bullseye routing on that queue and ensure all the members of the queue are in ring 2, this forces the in-queue call flow treatments to play before the routing starts reaching out to members on ring 2.  Hope this is clear, but it worked for us.  If you guys have any comments on this or other ideas to avoid the bullseye routing, that will be great, because it adds a layer of complexity that I wish I could eliminate.

Thanks

John,

There won't be an inbound call flow triggered, but the in-queue call flow should be. This is used by many folks to work around this issue including having "dummy" queues to transfer to, perform the treatment and then transfer to the "real" one. Another method is to have a dummy DNIS attached to an inbound call flow (which does the work) and the create an external contact for that DNIS so agents can do the transfer easily.

There are ideas out there (for example, this one) that would also solve this problem for you - I suggest you taker a look and comment / vote if you agree!

HTH

If an agent from Group 1 initiates a transfer to Group 2.  Because this is a direct transfer to a queue, none of the call treatments set forth in the Call Flow are being followed.  I am assuming this is correct behavior because the call doesn't go through the actual call flow.  Am I thinking about this correctly?

Hey Luis!

Yes, the issue with the in-queue flow not executing when an agent is available is why most folks use an intermediate ("Dummy") queue. You have a nice solution there, although it does mean that any "regular" (i.e. non-transferred) calls will get delayed slightly too.

I just wanted to expand on the "Dummy DNIS" suggestion, not just for you, but also for anyone else who stumbles across this thread. When you do this, the call never leaves Genesys Cloud, so the number does not need to be routable. What I've seen most people do is to use the infamous "555" exchange to avoid the very situation you describe. You simply create a DID/DNIS for (say) 317-555-1234 and then assign this to the route and on to the flow. You add this to the external contact. Even if the number gets "leaked" as you put it, it won't be dialable from outside the ORG.

For anyone reading this who doesn't know, the "555" exchange, is a bit like the 192.168.x.0 (and similar) IP networks. It's purpose it to provide numbers that are "safe" to use for internal purposes. It's also usually used (these days, anyway) in TV shows and movies so that the audience cannot try dialing it (and end up hassling some unsuspecting individual!) Once you know this, it stands out when watching these shows 😉

HTH

Hi John/Paul, this is an interest topic and already submitted my vote to the idea Paul provided, I believe, ultimately the solution is for Genesys to allow transfers to a flow.

Paul, I tried both work arounds you mentioned, and unfortunately those didn't work for us.  The issue with the "dummy" queue idea is that agents will lose visibility of how many agents are on that queue, and how many are idle before initiating the transfer.  For the dummy DNIS, issue is that those DNIS can be leaked to real customers and be used from the outside, possibly creating problems, especially if the queue you are trying to transfer to is an internal queue not meant to be called from the outside.

The work around I ended up implementing is this, and please stay with me here because it might be confusing to explain.  The work around I used was to replicate most of the treatments on the in-queue call flow, the problem with this, is that is not that simple, reason is, if you do a transfer to a queue, if an agent is idle, the call will be delivered and connect right away, without performing any treatments on the in-queue call flow.  So, to work around this and ensure the treatments are played, I had to turn-on bullseye routing on that queue and ensure all the members of the queue are in ring 2, this forces the in-queue call flow treatments to play before the routing starts reaching out to members on ring 2.  Hope this is clear, but it worked for us.  If you guys have any comments on this or other ideas to avoid the bullseye routing, that will be great, because it adds a layer of complexity that I wish I could eliminate.

Thanks

John,

There won't be an inbound call flow triggered, but the in-queue call flow should be. This is used by many folks to work around this issue including having "dummy" queues to transfer to, perform the treatment and then transfer to the "real" one. Another method is to have a dummy DNIS attached to an inbound call flow (which does the work) and the create an external contact for that DNIS so agents can do the transfer easily.

There are ideas out there (for example, this one) that would also solve this problem for you - I suggest you taker a look and comment / vote if you agree!

HTH

If an agent from Group 1 initiates a transfer to Group 2.  Because this is a direct transfer to a queue, none of the call treatments set forth in the Call Flow are being followed.  I am assuming this is correct behavior because the call doesn't go through the actual call flow.  Am I thinking about this correctly?