Genesys Cloud - Main

I think I may have found a workaround for this. I've done some testing and it appears to achieve the desired result...

By creating a very simple email 'in-queue' flow that contains only a 'Transfer to ACD' action, that is then assigned to the relevant queue, when an agent transfers the email interaction to the queue in question and the email is queued (99 times out of 100 within our environment the email will be queued) - the in queue action will execute, remapping the interaction to the queue in question but also 'stamping' the required priority upon the interaction (as defined within the in queue flow Transfer to ACD action). If that makes sense!

Nope. This isn't a solution. When the in queue ACD transfer sends the interaction back into the 'same' queue (with priority stamped) - it creates a little loop where the interaction keeps transferring itself back into the queue - this stops after about 10 cycles and leaves the interaction in the queue with the desired priority. However, these 'cycles' of the interaction repeatidly hitting the queue again are captured within the reporting 'stats' for the queue - reporting the 1 interaction as 11 (due to the loop routing of the interaction). 

Back to the original question - how do others deal with priority / skills stripping of email interactions when they are transferred from one queue to another? Surely there has to be a solution to this? 

I think I may have found a workaround for this. I've done some testing and it appears to achieve the desired result...

By creating a very simple email 'in-queue' flow that contains only a 'Transfer to ACD' action, that is then assigned to the relevant queue, when an agent transfers the email interaction to the queue in question and the email is queued (99 times out of 100 within our environment the email will be queued) - the in queue action will execute, remapping the interaction to the queue in question but also 'stamping' the required priority upon the interaction (as defined within the in queue flow Transfer to ACD action). If that makes sense!

Nope. This isn't a solution. When the in queue ACD transfer sends the interaction back into the 'same' queue (with priority stamped) - it creates a little loop where the interaction keeps transferring itself back into the queue - this stops after about 10 cycles and leaves the interaction in the queue with the desired priority. However, these 'cycles' of the interaction repeatidly hitting the queue again are captured within the reporting 'stats' for the queue - reporting the 1 interaction as 11 (due to the loop routing of the interaction). 

Back to the original question - how do others deal with priority / skills stripping of email interactions when they are transferred from one queue to another? Surely there has to be a solution to this? 

I think I may have found a workaround for this. I've done some testing and it appears to achieve the desired result...

By creating a very simple email 'in-queue' flow that contains only a 'Transfer to ACD' action, that is then assigned to the relevant queue, when an agent transfers the email interaction to the queue in question and the email is queued (99 times out of 100 within our environment the email will be queued) - the in queue action will execute, remapping the interaction to the queue in question but also 'stamping' the required priority upon the interaction (as defined within the in queue flow Transfer to ACD action). If that makes sense!

Hi Matthew,

You can save the priority in Participant Data, then in the Initial State of your In-Queue flow you get the value and set priority.

This will not show the correct priority in Queue Activity as it doesn't update the view when priority changes, but it will route based on the new priority.

Nope. This isn't a solution. When the in queue ACD transfer sends the interaction back into the 'same' queue (with priority stamped) - it creates a little loop where the interaction keeps transferring itself back into the queue - this stops after about 10 cycles and leaves the interaction in the queue with the desired priority. However, these 'cycles' of the interaction repeatidly hitting the queue again are captured within the reporting 'stats' for the queue - reporting the 1 interaction as 11 (due to the loop routing of the interaction). 

Back to the original question - how do others deal with priority / skills stripping of email interactions when they are transferred from one queue to another? Surely there has to be a solution to this? 

I think I may have found a workaround for this. I've done some testing and it appears to achieve the desired result...

By creating a very simple email 'in-queue' flow that contains only a 'Transfer to ACD' action, that is then assigned to the relevant queue, when an agent transfers the email interaction to the queue in question and the email is queued (99 times out of 100 within our environment the email will be queued) - the in queue action will execute, remapping the interaction to the queue in question but also 'stamping' the required priority upon the interaction (as defined within the in queue flow Transfer to ACD action). If that makes sense!