There are a few rare scenarios where an existing trigger can create an infinite loop with our Round Robin batch job. The batch job runs as frequently as once per minute, depending on your configuration, and it processes every unassigned ticket from your queue without skipping any that may have been previously assigned by the app.
If a trigger removes the Assignee, the ticket is returned to the queue immediately. Round Robin picks it up from the queue and reassigns it to another agent in the next job. As soon as the ticket is reassigned, the trigger fires again, removing the Assignee. If left unchecked, this loop can generate excessive ticket events and significantly degrade Zendesk performance.
Here's an example of what it looks like in the ticket event history:
Scenario 1: trigger removes assignee
You may have a trigger that removes the Assignee from incoming tickets to create a “blank slate” for triaging. In some cases, this is also used to prevent agents from cherry-picking tickets by firing when an agent attempts to assign a ticket to themselves. Because the trigger fires on ticket updates, it can also fire when Round Robin assigns a ticket. If this trigger exists, it can cause an assignment loop.
General solution
To prevent this, add the following condition to the Meet ALL section:
- Ticket: Playlist Assigned At > Not present
Why this works
This works because the app applies a timestamp to the Playlist Assigned At field on every ticket assignment. With this condition in place, the trigger will only fire for tickets that were not assigned via Round Robin.
It's simple and should be sufficient for most use cases.
Advanced solution
For a more robust safeguard, you can instead use the following condition:
- Ticket details: Current user > Is not > [Name of admin connected to app]
Why this works
The app assigns tickets under the permissions of the connected admin account. By excluding that admin from the trigger's conditions, the trigger will not fire when the app assigns tickets.
The main advantage of this approach is that it still allows the trigger to fire under legitimate circumstances, after round robin assignment has completed.
However, keep in mind that this approach requires you to update the condition if the admin changes.
Scenario 2: trigger reverts group excluding assignee
You may have a trigger that reverts a ticket’s Group when it changes, typically to enforce a specific group under certain conditions. The issue arises because Zendesk requires an agent to be a member of the ticket’s Group in order to be assigned. However, the app currently assigns tickets to agents even if they are not members of the ticket’s Group.
If the Assignee is not a member of the ticket’s Group at the time of assignment, Zendesk automatically changes the Group to the agent’s default group. Although our service does not modify the Group, this change still counts as a Group update and can cause the trigger to fire, reverting the ticket back to the original Group (or the Group in your trigger's Actions list).
Because the agent is not a member of that Group, Zendesk then removes the Assignee. This returns the ticket to the queue, allowing Round Robin to pick it up again and resulting in an assignment loop.
General solution
The solution here is the same as in Scenario 1. To prevent an assignment loop, add the following condition to your trigger:
- Ticket: Playlist Assigned At > Not present
Advanced solution
For a more robust safeguard, you can exclude the admin account used to authenticate the app by adding the following condition:
- Ticket details: Current user > Is not > [Name of admin connected to app]
Again, keep in mind that this condition must be updated if the admin changes.