Merging tickets
Merging combines two tickets into one when they turn out to be about the same thing — for example a customer raised the same enquiry twice (once via email, once via the support form), or a colleague started a duplicate while you were drafting a reply. Use Cloning for the opposite operation, and Ticket links when two tickets are related but should stay separate.
Selecting two tickets
Open the ticket browser. Tick the selection circle on each of the two tickets you want to merge. The action panel slides out on the right with a Merge tickets button. The button is enabled only when exactly two tickets are selected and you have manage rights on the current queue (see Queue permissions).
What Tickiti does
Click Merge tickets and confirm. There is no further dialog — no survivor to pick. Tickiti applies a fixed rule: the older of the two tickets (by creation date) is kept, and the newer is folded into it.
The merge process:
- Participants from the newer ticket that are not already on the older one are added to it.
- Responses from the newer ticket are copied onto the older one, with their attachments. Note that they are appended after the older ticket’s existing history rather than interleaved chronologically — reading the merged ticket you will see all of the older history first, then the newer ticket’s thread on the end.
- An audit note Merged ticket #N is recorded against the most recent response on the merged ticket so the join point is visible.
- The newer ticket is soft-deleted with a pointer (
merged_to_ticket_id) to the survivor, so its number is not lost from the database. - If the older ticket was on hold, the merge reopens it and notifies the assignee with a
[reopened]subject tag — you cannot quietly merge into a paused ticket.
What happens to the old ticket number
The most common reason this matters is that the customer might have the old (newer) ticket number in an email and reply to it. Tickiti’s mail pipeline looks the number up including soft-deleted tickets, follows the merged_to pointer, and posts the customer’s reply onto the survivor automatically. So email replies do land in the right place.
Direct browser navigation to the old ticket number is a different story: a staff member who clicks an old link or types the number gets a 403, because the merged-away ticket is no longer visible to the staff lookup. If you anticipate the old number being shared around (for example you replied with it before realising it was a duplicate), make a habit of merging earlier rather than later, or send a follow-up note pointing colleagues at the survivor’s number.
Reversing a merge
Merges are not automatically reversible. The merged-away ticket still exists as a soft-deleted row, but the responses that were on it have been copied (with new IDs) onto the survivor — un-doing a merge would mean unwinding all of that. If you merge in error the practical recovery path is to clone the relevant range of responses out of the survivor into a fresh ticket and edit it down to what you want. Easier to merge carefully than to reverse.