Rich Lorenzo

@Melissa I hear you! The potential for tickets getting lost due to this product shortcoming is very real!

Two things I'm doing that could help you with this going forward:

1. Create a ticket field called something like "Requested Through" and create your own concept of ticket channel. This will allow you to always have a tag on the original ticket to help inform ticket routing for when the ticket is generated through the "Closed Ticket" channel. Since the follow up ticket inherits the tags of the originating ticket you can use a trigger to evaluate the tags on the follow up ticket to see where it came in through (if you have more than one support address routing to more than one group this will be particularly useful) and then you can route the follow up ticket the same way you routed the original ticket. You'll need a second "closed tickets" trigger for every support address or ticket channel but this will at least make sure that these follow up tickets get routed to a group.

2. Create a view to monitor for tickets that are requested through the closed tickets channel and have no group assigned. This will help you notice when you missed something in setting up step #1.

The concept of the "follow up tickets" channel is in and of itself confusing and problematic.

It seems like it may have been some kind of shortcut to create an association between the closed ticket and the new ticket or just wasn't thought through completely. Why do these tickets have to be associated with a different channel altogether? I think that's really the source of the problem that is being discussed here.

+1 for this feature.

The URL target solution makes a lot of sense as a scalable solution, a shame it's not a "supported" approach.

I don't doubt there have been more important feature priorities over the past 6+ years but this is sort of table stakes here. The way this functions by default is just bound to be wrong for many more teams than it is correct.