Ticket Assignment Issue: All tickets assigned to one agent

Recently, we received a support request from one of our clients that a certain class of tickets were being automatically routed to one individual agent rather than to the group. We have seen this sort of issue before, so we were able to quickly get to work diagnosing the root cause. Of course, as the client you would be extremely worried about this happening, but as the Zendesk expert we just get right to sorting out the cause of the issue.

The objective for this case write up is to not only provide guidance on a solution for a specific issue, but to also outline a general troubleshooting approach for Zendesk issues. We use some similar tools for a wide-range of cases, and several troubleshooting principles are helpful for all Zendesk admin work as well as in general working with different software tools.

This sort of thing is a pretty common issue, so you can find help on Zendesk’s help centre or ask your favorite AI companion to help, but for an experienced Zendesk system administrator you already know right where to look.

- Why are my tickets automatically routed to a specific agent?

The first thing we need to do, just like most problems we try to solve, is to get some example tickets. If possible, we want to get one that exhibits the desired behavior and one that is malfunctioning to make it easier to compare.

Now that we've got the sample tickets, we should take a look at the group that the tickets are assigned to.

You can check in the event log for the actual event that assigns the ticket. Usually this will be a trigger, and you can click on the trigger in the event log to see the specifics.

Zendesk has a system rule which will assign tickets to an agent if the agent is the only agent in the group, or if the agent is the only assignable agent in the group.

In my case, the agent was not the only one in the group, and the trigger which did the assigning didn't actually have any action to assign to the agent. This was very strange.

One thing that can happen while troubleshooting, is that there is a period of time (hours, days, weeks) in between when the example tickets were created or updated and when we actually do the investigation. Sometimes this can hide the cause of the issue. It may be that the issue was already resolved due to the update, or it may not.

So in my case, the next thing to do was to check when each of the relevant resources was updated. First we checked the trigger using Zendesk's revision history tool. This makes it easy to see everything that has changed in the trigger and when it was updated. In this case, the trigger hadn't been updated in almost a year, so it couldn't be that it was setting the assignee previously and only recently updated.

Next, I checked the agent profile to see if he had been recently added to the group. The most recent update to his profile had happened before the incident in question, so again it couldn't be the cause of the issue.

At this point, I could not find any reason in the system why these tickets were always being assigned to this agent. This meant that it was time to contact Zendesk support. After making it past the Zendesk bot, I was able to submit my ticket. Having worked through these possibilities already, I was able to provide all of the information to the Zendesk agent immediately, which also sped up resolution time. Another thing to do is to enable account access so that way Zendesk support could go in and take a look without having to take additional time to ask for permission.

When the Zendesk agent got back to me, he first asked a few troubleshooting questions which I had already tried but had omitted from my support request. In the end, the agent was unable to find a reason for the malfunction and recommended to delete the group and re-create it. While I understand the troubleshooting value in this approach, there could be a significant downstream impact from doing so. Instead, I simply added myself to the group in question to see if it would resolve the issue, which it seems to have done. My profile appears in the ticket assignee drop-down as a second agent, and so this also means that new tickets coming in will be assigned to the group rather than to the individual agent.

This appears to be a short-term solution, but we still need to devise a long-term solution. So the next steps is to determine what is the ideal end state. In our case, the original second agent is actually scheduled to be removed from the Zendesk, leaving only one agent in the group. In this case, it is expected that the tickets would all be assigned to that agent. If an alternative is desired, then we would still need to determine some sort of alternative set up.