Merging Duplicates & Linking Major Incidents
Two tickets can be related for two different reasons — and QueueDesk handles them differently on purpose.
| Situation | Example | What to use |
|---|---|---|
| Same person reported the same issue twice | An employee emails support, then also raises a portal ticket for the same problem | Merge |
| Many people affected by one root cause | A server outage — ten employees each raise their own incident | Link to a parent ticket |
Using the wrong one causes real problems: merging ten genuine reports into one throws away nine requesters' tickets, and linking one person's duplicate under a "parent" leaves a pointless empty shell behind. The rule of thumb — if more than one person is genuinely affected, use linking, not merge.
Merging duplicate tickets
Open the duplicate ticket, use More → Merge into…, and type the other ticket's number. QueueDesk looks it up and shows you exactly what will happen before you confirm:
- •The older ticket survives by default — it keeps its number, its due dates, and its full history. This matches how most teams already think about it: the first report is the record of the incident.
- •The newer ticket is marked Merged. Its messages move into the surviving ticket's conversation, each one labelled with where it came from (e.g. "From INC-1005") so nothing reads as if it was said on the wrong ticket.
- •The requester of the merged ticket gets an email telling them their request was combined, with a link straight to the surviving ticket. If they reply to any earlier email about their original ticket, that reply is automatically routed to the surviving ticket too — it never gets lost.
A merged ticket is not deleted — you can still open it from search or from the surviving ticket's thread, but every field is read-only and a banner points you to where the live conversation continues.
Merging never creates a new ticket number. This is deliberate: a new number would reset the due-date clock (making an already-late ticket look on-time) and split the ticket's history across two records. The number you started with — the older one, or whichever you name as the survivor — is the number that continues.
Merge is a one-way action. There's no automatic "unmerge".
Linking tickets under a major incident
When one root cause affects several people, don't merge — link their tickets under a single parent instead. Every linked ticket stays completely real: its own number, its own requester, its own due date.
Linking one ticket
Open the ticket, use More → Link to parent…, and type the parent ticket's number.
Linking many at once
This is the common case for a major incident — you've just noticed five people reported the same thing. In the ticket queue:
1. Select the affected tickets with the checkboxes.
2. In the bar that appears at the bottom, choose Set parent and type the parent ticket's number.
3. All selected tickets link in one step. Tickets that can't be linked (for example, one that's already merged) are skipped and you'll be told how many.
What happens on the parent ticket detail page
A Related Tickets panel shows either the parent this ticket belongs to, or the list of linked child tickets with their status and requester. Unlink from there at any time — unlinking doesn't close or change either ticket, it just removes the connection.
What flows down from the parent, and what doesn't
| Action on the parent | Effect on linked children |
|---|---|
| Resolve or close | Every linked ticket that isn't already resolved/closed is automatically resolved/closed too, using the same resolution notes. Each requester gets their own "your request has been resolved" email. |
| Reply, marked "also post to linked tickets" | Copied into every linked ticket's conversation, and each requester is notified. This is opt-in — a reply isn't broadcast unless you choose to. |
| Priority, assignee, group | Never changes on linked tickets. Each one keeps its own workload and its own due date — a linked ticket that's genuinely running late is still genuinely running late. |
| Reopening the parent | Does not reopen already-resolved linked tickets. |
A ticket can only be linked one level deep — a parent can't also be someone else's child, and a ticket with its own linked tickets can't become a child itself. This keeps "what happens if I resolve this" always unambiguous.
Reclassifying a ticket's type
If a ticket was logged as the wrong type — say, an Incident that was actually a Service Request — open it and click the Type field in the sidebar to change it. The ticket keeps its original number; only its type and workflow rules (approvals, due dates) change to match the new type.