[object Object]

What Merge Actually Does

Freshdesk’s “Merge Ticket” function combines two or more tickets into a single primary ticket. The secondary tickets get the status “Closed” with a note pointing to the primary, and their conversations are appended to the primary’s thread. That’s the marketing-page summary. The full reality is more surgical, and four things drop that customers and auditors care about.

Once a merge is done, the secondary ticket IDs still exist as redirects, but the merge is not undoable. Like Zoho’s Multi-Currency switch, this is a one-way door. Audit before you click.

The Four Things You Lose

1. Conversation timestamps interleave by send-time, not by ticket. When you merge a 10-message ticket from Tuesday into a primary ticket from Monday, the primary’s thread now shows Monday morning, then a chunk of Tuesday’s messages, then Monday afternoon. Agents reading the merged thread can’t tell which messages came from which original conversation. The fix is a hand-typed note at the merge point — Freshdesk doesn’t insert one automatically in 2026.

2. Custom field history is overwritten by primary. If the secondary ticket had a custom field “Resolution Code” set to “Escalated,” and the primary’s was set to “Resolved,” the merged ticket shows “Resolved” only. There’s no “previously was Escalated on secondary T-12345” trace in the activity log. Reports that filter by Resolution Code now under-count the Escalated bucket by the number of merged tickets.

3. SLA timeline collapses to the primary’s clock. The secondary’s SLA timer stops at merge time and is no longer reflected in compliance reports. If the secondary breached SLA before merge, that breach is gone from the rolling compliance window. Inside-out: you can game compliance reports by merging breached tickets into compliant ones. Most teams don’t do this intentionally, but it shows up in audits.

4. Survey responses tied to secondary tickets don’t move. A CSAT survey sent on a secondary ticket stays attached to the secondary’s ID. When the secondary closes via merge, the survey often arrives at the customer with the secondary’s reference, but it counts against the secondary in CSAT reports. The primary, which the customer actually experiences, gets no survey. This is the most common cause of CSAT response rate gaps in teams that merge frequently.

What You Can Recover

Some of the lost data is recoverable via the Freshdesk API. Specifically:

  • Conversation order by original ticket: query the secondary’s ticket ID directly via GET /api/v2/tickets/{id}/conversations. The thread still exists; it’s just not visible in the merged UI.
  • Custom field history: pull the activity log of the secondary via GET /api/v2/tickets/{id}/activities. Field changes are recorded with timestamps.
  • SLA timer values: the secondary’s resolution_status_metric field is preserved.

Survey responses are the exception — those are not recoverable in any clean way; you’d need to manually map the survey-to-ticket relationship in your data warehouse if you sync there.

The Pre-Merge Checklist

Before merging, run this in 30 seconds:

  1. Is either ticket in a breached or near-breach SLA state? If yes, document it before merging. Capture the secondary’s first_response_time and resolution_time as a note on the primary.
  2. Do the tickets have different custom field values? Pick one as the survivor and note the other on the primary ticket. The merge will silently drop the loser.
  3. Has a CSAT been sent on either? If yes, decide whether to resend on the primary after merge. Default: yes, with a note explaining the consolidation.
  4. Different requester emails? Merging across requesters changes the primary’s requester to the primary’s original — the secondary’s requester loses access. If the secondary’s requester is a real person, they need an alert or you’ll get a “ticket disappeared” complaint.

The Pattern That Avoids the Loss

For tickets that are clearly the same conversation across two channels (email + chat from the same customer), use Link Ticket instead of Merge. Link preserves both as independent tickets, shows the relationship in the sidebar, and keeps all history intact. The primary you work in is whichever one closes the loop with the customer; the linked ticket gets a status of “Resolved – Duplicate of TX-####” and stays in audit reports correctly.

The trade-off: linked tickets count separately in ticket-volume reports. For most teams, that’s the right answer — you handled two channels, count them as two. Merge if and only if you genuinely have a duplicate that shouldn’t have been two tickets.

What 2026 Changed

Freshworks added a “Merge Note” template option in 2026 Q1 — when configured, the merge automatically inserts a system note in the primary’s thread with the secondary’s ID, original timestamp, and a snapshot of its custom fields. It is not on by default. Most teams I audit in 2026 haven’t enabled it. Turn it on under Admin → Workflows → Merge Settings. Two minutes of work saves the conversation-order confusion entirely.

What to Do This Week

Open Admin → Workflows → Merge Settings and enable the Merge Note template. Pick a one-line format that includes secondary ID and original priority. Then pull a count of merges in the last 30 days from your activity log; if it’s higher than 10% of resolved tickets, you have a triage problem upstream, not a merge problem downstream.

[object Object]
Share