Automatically assign a follow-up ticket to the original group / assignee

Hello Zendesk. We are also struggling with this. We are an enterprise customer with multiple brands, multiple forms, multiple groups. We have 4 new groups onboarding with very high ticket volumes. There is a high percentage of Follow-Up tickets that have to be manually assigned to the group they originated from. I cannot understand how a new ticket emailed in can follow triggers to map to the correct groups but the follow-up tickets cannot follow that same path, they retain every other bit of form information. Is there a workaround that does not require a bunch of additional triggers to facilitate this? Thank you to anyone who has advice on this.

Hello 411901252

Thanks for reaching out in the Community!

If I understand correctly, your triggers set up to route tickets to the correct agents/groups work perfectly well for newly created tickets, but are not applying to follow-up created tickets. Is that correct?

Not being able to see the specifics of the triggers, I can't say exactly what the solution would be, but I've outlined an example below that might be what you're dealing with or at least provide useful concepts you can apply to your situation:

Imagine you had a trigger that routed all tickets created through the Web Widget to a certain agent group:

In this case, the trigger won't apply to follow up tickets because follow up tickets are actually created through the channel "closed ticket". So you can either clone that trigger and create an identical one where you change that one condition to "Channel is closed ticket". Or if you have no conditions in the "any of the following" conditions section, you can do this:

That's just one solution to one scenario. But hopefully it helps!
If you'd like to share an example of a trigger/scenario you have where the follow ups aren't routing correctly I can definitely tackle that specifically and try to get you up and running! If you'd prefer to work on this in a private ticket we can do that as well.

Let me know!

Elissa - 

My large enterprise organization has the same challenge as Jennifer's. The issue with the trigger you shared is that we have no way to identify what group the ticket previously belonged to, which is instrumental for the "group = support" action. We have many groups per brand that consist of very different groups of resources that support very different products and services. As such, we cannot just assume that a ticket belongs to a given group based on the brand for which the ticket was created (and channel being closed ticket) - we need to know which group or assignee was handling it. Are there any other ways?

As it stands right now, we are forced to tell our end users to create a new ticket when they attempt a follow-up, because the effort it would require to manually distribute these tickets to the appropriate groups would be cost prohibitive for our agents.

Would love a solve for this one as well. We have many different groups, but the Group doesn't get attributed to follow-up tickets, so we can't send follow-ups 'back' to the group it belongs to. If there's a fix for this in the roadmap, that would be great to hear.

@aileen11

If you haven't found a solution yet, I can help with this: sign up with the API Lookup app and I can configure it to automatically fill in the Group for follow-up tickets.

We have the same issue here at my large enterprise. We have many groups supporting the entire HR function. 

Basic concept:
Colleagues submits a form. 
That form can get moved between 2-6 different groups 
Ticket is solved
Ticket is closed
Colleague creates follow up
Ticket either goes back to the initial group rather than the solving group

Tickets are private so different groups can't see other groups tickets. I end up stuck and using 3 triggers per group would result in thousands of triggers!

Same issue here. We need a better way to handle follow-up tickets with users.

This is the way I think could work for everyone. It includes a few triggers and tags.

Follow-up tickets inherit tags. We can use this to assign them to the group the original ticket was assigned to. For this, I add a unique tag per group on every ticket created. 

Assignment trigger:

1. Ticket is created, assign to group1
2. Add tag tag_group1

Remove tag trigger:

If the ticket is updated and assigned to a different group (e.g., group2), remove tag_group1, add a new tag of the newly assigned group (e.g., tag_group2). This helps avoid assigning a follow-up ticket to the wrong group.

Follow-up group assignment trigger:

Conditions:
Actions: 
Assign to the group. 

DONE. 

Fernando's workaround does work, but you have to have a separate one for each group (or agent) and that may not be practical for all uses.  It really seems like the ability to create a follow-up should go hand-in-hand with the ability to reassign.

But, of course, it also seems like merging should come with an unmerge.

The software is cool, but I am shocked we don't have an option of Auto reassigning of Follow up tickets.

I tried to explain to the support agents of Zendesk even though they are not understanding it,  strange - But I could see most of us facing a similar problem.

Example: 

I have 2 agents A & B.

Our client raised an issue requesting to change his account mobile number and the client didn't share the mobile number in the first email. And the ticket id is 100.

So the ticket first got assigned to agent "A". And agent A requested the client to share the mobile number so he can update it to the account, then agent A kept the ticket in "Follow up/ Pending"

The agent is done with his shift and logged out.

After agent "A" is logged out, the client replies to the same email chain the ticket id is 100 -- and the client says this is my mobile number please update it.

Here my agent B is online now, but agent B is not been assigned that specific ticket: 100.

1) The biggest challenge is that these replies are going to agent A's follow-up ticket.

2) Till Agent A joins the shift the client has to wait, but agent B is not been reassigned with the ticket.

This is the biggest challenge or drawback I could say and it would be a bigger issue for us to use this tool...

I wish someone could help us on this, but seeing the above comments it makes me think Zendesk doesn't have it :-(

This seems like a no-brainer feature that any CSM product should have. Add it to the list of disappointments and missing features that likely would have steered my large organization to a different product if we'd known about them in advance. This is a major hassle for us, and frankly a major fail for Zendesk. We have so many groups across different bureaus that the suggested workarounds are absurdly inadequate.

Hey everyone, thank you for taking the time to provide us with this product feedback. We apologize for the delay on our end in providing you with a response to the feature request.

I work in managing our customer product feedback forums and have been in communication with the product team that owns this area. They noted the following: this is a great feature request and we have added it to the backlog for future consideration. This means that we will think about adding it as a priority later in our planning cycle. We are going to leave this post open for comment to allow others to provide their feedback and use cases, however please note as is stated in our Community Guidelines that we can not commit to prioritizing any one piece of feedback we receive in the community. 

If you are interested in learning more about this and other features being built please make sure to check out and follow our Community events, What’s New Community Topic, and Zendesk Updates. Again, we apologize for our delay and appreciate you being a valuable Zendesk Community member.

Thank you again for your feedback and for being a valuable customer with Zendesk.