Genesys Cloud - Main

Do anyone have a solution to if an agent transfer a workitem to a new queue. I would like to get new configuration with skill, priority for this workitem. Since there is no in-queue flow for workitem I'm looking for another way. I have used a status change on the workitem before transfer it to a a queue. This status change remove skill from the interaction. But it runs before the agent manage to transfer to new queue. Therefor the queueid is the old queue.

Wass looking into to triggers. I found a trigger for task management. This work without filter, but I want it to only trigger when a transfer is done. Looks like the status on the interaction changes to unassigned so I though of using that, but it doesn't trigger.

Anyone have som tips?

#DigitalChannels
#Routing(ACD/IVR)

------------------------------
Eystein Kylland
Systemutvikler Genesys Applikasjonsspesialist
------------------------------

Hi Eystein,

I would first look at Workitem Flows before trying to solve this with Task Management triggers.

Unlike voice, messaging, or email, Workitems do not have In-Queue Flows, but Genesys provides dedicated Workitem Flows that can automate workitem processing throughout its lifecycle. Workitem Flows can read and update workitem attributes, priority, status, assignee, and even transfer workitems to users or queues. They can also execute automatically based on workitem events such as status changes.

One thing that caught my attention in your design is that you're updating the status before the transfer occurs. At that point, the workitem is still associated with the original queue, which explains why you're retrieving the old queueId.

Instead of trying to act before the transfer, I would investigate whether you can:

• Transfer the workitem first.
• Use a status transition after the transfer is completed.
• Trigger a Workitem Flow from that status change.
• Recalculate priority, skills, or other attributes based on the current queue assignment.

I haven't found documentation indicating that a queue transfer itself directly triggers a dedicated event that can be filtered natively, so I'd be cautious about relying on Task Management triggers for transfer detection alone.

If Workitem Flows cannot provide the exact event timing you need, then an event-driven approach using APIs and external automation may be required. However, I would exhaust the Workitem Flow capabilities first since they are the native mechanism designed for workitem lifecycle automation.

https://help.dev-genesys.cloud/articles/work-with-workitem-flows/

------------------------------
Gabriel Garcia
NA
------------------------------

There is one problem. If you transfer using the transfer button and select a queue the workitem is transferred and removed from agent. You are then not able to change the status.

------------------------------
Eystein Kylland
Systemutvikler Genesys Applikasjonsspesialist
------------------------------

Original Message:
Sent: 06-02-2026 09:47
From: Gabriel Garcia
Subject: Problem when transfer a workitem to a new queue

Hi Eystein,

I would first look at Workitem Flows before trying to solve this with Task Management triggers.

Unlike voice, messaging, or email, Workitems do not have In-Queue Flows, but Genesys provides dedicated Workitem Flows that can automate workitem processing throughout its lifecycle. Workitem Flows can read and update workitem attributes, priority, status, assignee, and even transfer workitems to users or queues. They can also execute automatically based on workitem events such as status changes.

One thing that caught my attention in your design is that you're updating the status before the transfer occurs. At that point, the workitem is still associated with the original queue, which explains why you're retrieving the old queueId.

Instead of trying to act before the transfer, I would investigate whether you can:

• Transfer the workitem first.
• Use a status transition after the transfer is completed.
• Trigger a Workitem Flow from that status change.
• Recalculate priority, skills, or other attributes based on the current queue assignment.

I haven't found documentation indicating that a queue transfer itself directly triggers a dedicated event that can be filtered natively, so I'd be cautious about relying on Task Management triggers for transfer detection alone.

If Workitem Flows cannot provide the exact event timing you need, then an event-driven approach using APIs and external automation may be required. However, I would exhaust the Workitem Flow capabilities first since they are the native mechanism designed for workitem lifecycle automation.

https://help.dev-genesys.cloud/articles/work-with-workitem-flows/

------------------------------
Gabriel Garcia
NA
------------------------------

Good point, Eystein.

If the agent is using the native Transfer action to send the workitem directly to another queue, then you're right-the workitem leaves the agent's ownership immediately and the agent no longer has an opportunity to perform a status change afterward.

In that case, I think the real question becomes:

"How can we detect that the destination queue has changed?"

Looking at the current Workitem Flow capabilities, I don't see a native event specifically for "queue transferred" that would allow us to execute logic exactly at that moment.

Because of that, I would investigate whether the destination queue change is exposed through:

• Task Management triggers
• Event notifications
• Workitem APIs (polling/reconciliation)
• Custom transfer process instead of the native transfer button

One alternative might be replacing the standard transfer process with a custom action where:

1. The agent selects the target queue.
2. A Workitem Flow or API process updates the skills/priority first.
3. The workitem is then transferred programmatically.

That would give you control over the order of operations, although it does add complexity compared to the native transfer experience.

------------------------------
Gabriel Garcia
NA
------------------------------

Original Message:
Sent: 06-02-2026 10:00
From: Eystein Kylland
Subject: Problem when transfer a workitem to a new queue

There is one problem. If you transfer using the transfer button and select a queue the workitem is transferred and removed from agent. You are then not able to change the status.

------------------------------
Eystein Kylland
Systemutvikler Genesys Applikasjonsspesialist
------------------------------


Original Message:
Sent: 06-02-2026 09:47
From: Gabriel Garcia
Subject: Problem when transfer a workitem to a new queue

Hi Eystein,

I would first look at Workitem Flows before trying to solve this with Task Management triggers.

Unlike voice, messaging, or email, Workitems do not have In-Queue Flows, but Genesys provides dedicated Workitem Flows that can automate workitem processing throughout its lifecycle. Workitem Flows can read and update workitem attributes, priority, status, assignee, and even transfer workitems to users or queues. They can also execute automatically based on workitem events such as status changes.

One thing that caught my attention in your design is that you're updating the status before the transfer occurs. At that point, the workitem is still associated with the original queue, which explains why you're retrieving the old queueId.

Instead of trying to act before the transfer, I would investigate whether you can:

• Transfer the workitem first.
• Use a status transition after the transfer is completed.
• Trigger a Workitem Flow from that status change.
• Recalculate priority, skills, or other attributes based on the current queue assignment.

I haven't found documentation indicating that a queue transfer itself directly triggers a dedicated event that can be filtered natively, so I'd be cautious about relying on Task Management triggers for transfer detection alone.

If Workitem Flows cannot provide the exact event timing you need, then an event-driven approach using APIs and external automation may be required. However, I would exhaust the Workitem Flow capabilities first since they are the native mechanism designed for workitem lifecycle automation.

https://help.dev-genesys.cloud/articles/work-with-workitem-flows/

------------------------------
Gabriel Garcia
NA
------------------------------

@Eystein Kylland,

I would suggest you to try use the agent script to transfer the workitem to a flow, in this way you could reset the skills before transfer to the new queue.

Regards,

SG 

------------------------------
Saugort Dario Garcia
Arquitecto de soluciones
------------------------------

I found a way. In the script I change the skill on the workitem with dataaction to a skill that everyone have. Then you only have to be member of the transfer queue to get the interaction. It look like that is the solution. I thought of doing transfer in the script, but then the agents needs to use different transfer method on different media. That will make the agents confusion, but a good suggestion. 

------------------------------
Eystein Kylland
Systemutvikler Genesys Applikasjonsspesialist
------------------------------

Original Message:
Sent: 06-03-2026 11:02
From: Saugort Dario Garcia
Subject: Problem when transfer a workitem to a new queue

@Eystein Kylland,

I would suggest you to try use the agent script to transfer the workitem to a flow, in this way you could reset the skills before transfer to the new queue.

Regards,

SG 

------------------------------
Saugort Dario Garcia
Arquitecto de soluciones
------------------------------