Why does Chat update the assignee or group of an ended chat?

Return to top
Have more questions? Submit a request


  • Davide Troise

    Hi Anna, 

    This behavior is wrong for SO MANY REASONS and is giving issues to a lot of Zendesk customers. 

    Most of the triggers for chat tickets use the first comment to decide whether to fire or not, and maybe assign the right group based on the first comment. Thanks to the behavior you explained, now the only solution would be applying a tag based on the first comment, and then when the tag zopim_chat_ended is added we should read the tags added earlier and assign the ticket to the correct group. And this is not how things worked, so now a lot of instances should duplicate their triggers. 

    Really NOT well done to whoever decided this update. 

  • Rob

    I have to agree with the comment earlier. It was extremely frustrating to find that effective agents, who tag and assign tickets during a chat or immediately after are having their work undone by your trigger just because it takes some time to run.

    We have found tickets being reassigned to frontline agents when they were supposed to have been escalated.

    It is not always possible to just wait for the trigger to run as there are other tickets coming in, so this needs to be looked at again

  • Harrison Crerar

    This functionality hinders the efficiency of our agents, and creates a risk to how our support is branded.

    Because our agents support multiple services, having the chat assign a ticket to an agent's default group means that they need to spend time after their support ticket updating the Brand, Group assignment, Forms, and Tags.

    Additionally, new Chat tickets are being assigned an agent's default group before a chat is concluded. This can cause confusion for both the agent and the end-user, especially if branded emails need to be sent to the end-user during or after the chat conversation and the relevant Brand/Group have not been properly assigned.

  • Roman Sheydvasser

    Similar to Rob's comment, our team's goal is to make sure a ticket lands in the right person's queue after a chat ends, and having that effort undone can be very frustrating.

    The ability to end the chat on the user's side as well (similar to other chat systems) would help in making sure the ticket isn't re-assigned on its own because a user forgot/didn't explicitly end the chat on their side:


  • Mateusz S

    Hello, is there any update on this? This behaviour is really making it difficult for our frontline agents to escalate tickets since tickets are sometimes reassigned back to agents by Web Service even 40 minutes later.

  • Ben Van Iten
    Zendesk Community Team

    Hi Mateusz S,

    Our product managers are aware of this limitation and I certainly understand that it can wreak havoc with some workflows. As you likely inferred from the article, this is expected behavior at this point. There isn't anything on the road map on the moment to address this but I will definitely mark this as product feedback so it can be reviewed again by the correct team internally.

    I know that isn't an immediately satisfying answer, but we do appreciate you sharing your thoughts on this.

  • Laura Curling

    Hi Ben,

    I am also having the same issue whereby tickets that have been sent over to other departments are being re-routed back to 1st line.

    Is there any known workaround for this that you can advise (or anyone else) to set up a trigger to re-routing automatically back to the correct department?

    Kind regards,


  • Ben Van Iten
    Zendesk Community Team

    Hi Laura,

    Are you referring to chats that were routed/transferred to an agent from a different department mid chat, or are you referring to the ticket itself after the chat is over?

    If it's the former, there is a setting in your chat account that determines if the ticket is assigned to the first agent that takes the chat or the last one that the chat is with after it comes to Support. This is under Settings>Account>Zendesk Support>Ticket Assignment.

    If the ticket is being reassigned after the ticket is created, and it is related to the behavior talked about in this article, there is not a workaround that I know of at this point. However I would recommend looking at the ticket events and determining if there is a Support trigger at play that is causing the reassignment.

    It's possible I'm misunderstanding you though. Feel free to explain your workflow/what is occurring in more detail and I'll be glad to try to help further!

  • Laura Curling

    Hi Ben,

    Thank you for coming back to me, unfortunately it is the latter.

    In our company a Customer Support agent takes a Chat, if the issue cannot be solved by them and must go to another department (Our Developers for example who don't use chat) the agent will end the chat from their side, forward the ticket over to the relevant department. At this point if the customer ends the chat from their end, it will move the ticket from the Developers back to the original Chat agent.

    Many people on articles have spoken about the use of triggers to place it back in the correct location, and I wondered if this is possible?

    I have already set up a trigger to alert me whenever a ticket is passed back for this reason.

    However, this is a very large flaw. If we pass over an urgent ticket to another department, and it happens to have gone back to the original agent that is not currently working, it may not be seen or picked up making the company react poorly to an urgent issue.

    Kind regards,


  • Ben Van Iten
    Zendesk Community Team

    Hi Laura,

    That definitely makes sense. Thanks for the background. I don't know how effective a trigger would be, as they are event based. I think what might work out for you, is a workflow where instead of transferring the ticket right away, your agents add a tag to the ticket and then an automation moves the ticket over in the next hour.

    This automation will look for any tickets hanging out there that are with a team of your choice, and have a certain tag on the ticket, and then move it over to another team. You could even add a condition for it to only look for tickets that were created more than a few hours ago just so you give customers time to close the chat.

    Does this make sense? I know it's not a perfect solution and has a slight time delay, but I think it gets around some of the issues you were having.



  • Michael

    I am having the same issues as Laura above and with our SLA's we cannot account for the "few hours ago" time frame, which I wouldn't consider a "slight time delay".  I would appreciate it as well if this could be brought up.  Our agents are trained to hit "end-chat" after their conversations, however, the customer is still able to do this same action which results in the changing of the ticket assignee and group.

    Our Tier 2 team is struggling with this, as they start working the ticket right away upon escalation, then it just disappears from their queue and they are no longer the assignee (this prevents them from even seeing the ticket until our Tier 1 team RE-ESCALATES) which is taking 2 agents away from helping customers effectively.


  • Tom Verkooijen

    I have the exact same scenario and problem that Michael highlights with one of my clients. The problem is that for end users it is not intuitive to end the chat. So most likely it times out after 20 minutes, when the chat agent has already moved on to other tickets/chats. And with the SLAs being 30 minutes on urgent issues, we can't wait 20 minutes to make the Tier-2 assignment, or wait for an hourly automation to make the Tier-2 assignment.

    It is a major productivity and service level inhibitor. Is there any line of sight into a solution for this? The only thing I could think of was making agents set a Tier-2 team (of which there are 15) on the chat via a tag, and when the zopim_chat_ended tag is set, re-assign the ticket to the Tier-2 team based on that tag. But if the ticket was already assigned to a specific agent, that agent assignment is undone, which is still very frustrating to the Tier-2 team. However... the zopim integration that assigns the ticket to the chat agent and default group appears to always as a final step be assigning the agent to the chat user. So even though the trigger looks for the condition that the group is set back to support, and that condition is met, the zopim integration fires after the triggers are run, so there really is no event we can anchor on to affect that.

  • Trevor Kanaya

    Just went through literally the exact same odyssey as Tom. Each ticket escalation macro adds a tag unique to the team it's being escalated to, and I thought maybe we could use this to create a trigger (unfortunately, one for each macro of which there are dozens, but would have been willing to do the work if this would be a solution) that would catch the reassignments by the Zopim integration and reassign them back to the intended escalated group.


    1. Zopim action would happen after so all of this would be pointless, and
    2. Even if it did work, we'd still have the aforementioned issue where if the ticket had been assigned to an agent within the escalated team, that assignee would be stripped and you'd be back to it being only in the group with a null assignee, which is far less than ideal.

    I was even into the weeds with Zapier seeing if there was a way we could reroute those tickets in a "smart" way but unfortunately there's no way to say "change it back to the group and/or assignee that it was prior to 'x' update". "Current user" won't work because if the escalated agent has assigned the ticket to themselves but hasn't updated it yet, then the ticket will just go back to the original agent that served the chat. Every possible solution is riddled with holes.

    If anyone else comes up with a solution to this, I'm certain this will help a lot of people work around this currently very faulty assignment logic.



Please sign in to leave a comment.

Powered by Zendesk