Ticket merging - a mess?


Here's what I expect from ticket merging: all timestamped interactions are shown in their original sequence. So, if I merge two or three tickets, I expect a larger single ticket that maintains an exact chronology of all the interactions, because two different tickets may have overlapping interactions.

However.. what seems to me that is happening in merging, is that one ticket is simply *added* to another. And I expect *intersection*.

Or am I getting things wrong? All I know is that merging in OTRS just works and makes sense, and after moving to FD I get headaches when trying to make sense out of merged tickets! Is it just me?


20 people have this problem

Agreed.  I've merged tickets & while it shows that they have been merged, when I go to my "All Tickets" view I still see all of the merged tickets listed separately.  The tickets that merged should not show in the ticket view list - they should only show in the ticket they were merged into.  Is this just Freshdesk being slow or is this an error?  Merging tickets is supposed to take you from multiple tickets to just 1.  That 1 should be the only ticket you see anywhere in Freshdesk - except of course, in that ticket's history.

I wholeheartedly agree with both Rodrigo (on merged ticket chronology, which is a complete mess) and Samantha on (on the fact that merged tickets still have lives of their own).
Freshdesk Support:  I believe an entry of mine (https://support.freshdesk.com/support/discussions/topics/304867) should be merged with this ticket, as it describes the same issue.
Hi Freshdesk, Any news on this?  I'm merging tickets this morning and this is really really bad -no-one could make sense of what happened with the customer and in what order. 

Wow, this is really bad indeed. 2yrs and no fix???

I am also one of the users that need this. If possible, I would prefer to have an option for how tickets are merged, as in the following image:

 BTW, the current appearance the comment 'Conversations from the merged tickets will be added to the primary ticket' is misleading.

This is absolutely terrible. "Messy" is an understatement. Not only do merged tickets simply appear one after the other (regardless of the chronology of the interactions they contain), in many cases the order of the interactions within a single ticket gets muddled.

For example, I merged two tickets as follows:

Ticket 123

Interaction A

Interaction B

Interaction C

Ticket 456

Interaction D

Interaction E

Interaction F

Upon merging Ticket 456 into Ticket 123, the end result was:

Ticket 123

Interaction A

Interaction B

Interaction C

Interaction F

Interaction E

Interaction D 

This is not only unhelpful - it's actively confusing and results in terrible customer service.

What I have noticed is that out of the 2 private notifications added in the "master" ticket, one should, in my opinion, have a different timestamp:

The private note with content "Ticket with id 4598435 is merged into this ticket." is correctly added with a timestamp that shows when the note was created ( i.e. when the merging happened ).

The private note with content "Merged from ticket 4598435" plus the contents of the "slave" ticket request is also added with a timestamp that shows when the note was created ( i.e. when the merging happened ). I believe that this note should have the timestamp of the original ticket request of the "slave" ticket and also have some extra div class qualifier: <div class="commentbox commentbox-gray private-note original_request_copy"> Doing this, will make the timeline look more consistent and there will be a way to make that note more visibly distinguishable.

In my opinion, ticket merging in Freshdesk has improved greatly in the past few months.
Freshdesk anything in the road map to further improve merging? There are still issues and work to be done here. Merged tickets should not be shown in the recent tickets or tickets of a customer. It is extremely confusing to agents. Merged tickets should instead be properly positioned into the parent ticket. Also, in another conversation we talked about the ability to report on Merged Tickets.

Hi Guys, 

Really sorry for keeping you all in the dark regarding this feature. We've made some major changes to the merge functionality in the last few months which should've improved it's performance. Having said that, we agree it needs more improvement. We've consolidated this list and sent it across to our product managers. We'll make sure to keep this thread updated once we hear back from them. 



I just merged two tickets, and I have lost all the detail of the "sub-ticket."  Under both the original ticket number and the new master ticket, I have only the original message that was used to create the merged ticket and a note indicating that it was merged.  The other 10 messages in that thread have apparently vanished.

I will open a ticket about this, but I thought I would mention it here.


Guys this is STILL terrible!

I just merged two tickets. It was a really simple one - all of the ts from the second ticket were added in reverse order.

Now if you read the ticket from top to bottom, it goes:

Ticket 1 Post A (original post)

Ticket 1 Post B

Ticket 1 Post C

Ticket 2 Post C

Ticket 2 Post B

Ticket 2 Post A (the original post from the second ticket.

All of the posts in ticket 1 were posted chronologically earlier than those in ticket 2, so there shouldn't be anything complicated here!!

While this gets sorted out, can we PLEASE have the functionality to MANUALLY re-order posts within a ticket? This is a nightmare!

I spent a bit of time on this, and I figured out what Freshdesk was doing -- not that I agree.  When you merge two  tickets, a note gets added to the first message in the sub-thread.  This changes the datestamp off that message to "now".  As a result, in a chronological listing, that first message will appear at the bottom of thelist.  All of the responses to that message will be above it, in their proper order.  It's only that first message that has a problem.

This is awfully confusing, because Freshdesk encourages people to start reading threads from the bottom.  Anyone reading that "last" message in the thread.will assume that there were no responses to it  Or --- if the reader knows that there really were responses -- may assume (as I did) that those were somehow lost in the merge.

Hi guys!

I recently have a trial FreshDesk and spent some time on the merging. Many people (including me) think that the merged tickets should NOT have lives of their own.

But consider the following imaginary case.

I have Ticket A and TIcket B created by two different customers by email.

An agent responds to both tickets, so both customers receive an email.

Next, ticket B is merged into Ticket A. Assume that Ticket B would disappear on this merge.

Now imagine that the customer of Ticket B would reply to his email he received earlier.

How could this work? Because Ticket B is gone, there is no way for the system to relate that incoming reply (which originated from Ticket B) to Ticket A.

Any idea?

Login or Signup to post a comment