Merge related support tickets
Choose one continuing ticket without rewriting past conversations.
Merge a duplicate source into a chosen target, redirect future channel references and keep the source history and conversation where they were recorded.
Two requests may describe one issue, but that needs human judgment.
A customer may submit a form and also send email about the same issue. Before merging, compare the actual request, requester, audience and current work. Similar subjects alone are insufficient. Choose which ticket should continue and explain the decision internally. A merge coordinates future handling; it does not prove that both reports were duplicates, that every recipient can see every message or that the issue is resolved.
Choose a valid source and surviving target.
Both tickets must be visible to the operator and the required update authority applies. A ticket cannot be merged into itself. Already merged or closed tickets cannot be used as ordinary source or target in this operation. The source revision is checked to prevent acting on stale state. Review the latest record if a colleague changes it while the merge is being prepared.
- Visibility, lifecycle and revision checks before merge
Understand what moves and what remains historical.
The source is closed and points to the target. Channel references and widget sessions move to the surviving ticket so later messages through those references reach the continuing case. Tags are combined. Historical messages and field history remain where they were written. This is deliberately different from copying every previous message into an invented single chronology or erasing the source record.
- Future routing moves; original conversations and history stay recorded
Review the continuing conversation after the decision.
Inspect the target's current team, assignee, status and next response. Read the historical source where needed rather than assuming the target now contains every prior message inline. Explain the continuing route to colleagues and test a later customer response through the relevant channel. Merging does not automatically send a resolution notice, replace a reviewed public reply or guarantee that unrelated external copies disappear.
- Reviewed handover to the target instead of automatic resolution
A concrete workflow
Compare
Read both requests and confirm they belong together.
Choose target
Select the ticket that should carry future handling.
Merge
Confirm authority, current source revision and lifecycle eligibility.
Verify routing
Inspect the target and test the next relevant customer reply.
An illustrative working example
Illustrative scenario: a form request followed by email
A customer submits a problem through a form, then emails the service address with further detail. An agent compares both tickets and chooses the email case as the continuing target after checking ownership and context. The source closes with a reference, and tags are combined. Historical form discussion stays in its original place. The team tests the next channel response and documents where colleagues should look for the earlier investigation.
Questions about this topic
Are old conversations copied into the target?
No. Conversations and history stay where recorded; future channel references move to the target.
Can closed tickets be merged normally?
This operation rejects closed or already merged source and target cases. Review lifecycle eligibility first.
Does merging solve the issue?
No. It organizes continuing work. Investigation, status decisions and public replies remain necessary.
Do I need access to both tickets?
Yes. Both must be visible and update authority is required. The source revision is checked.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
Zendesk
Application concept: Review two Zendesk reports for actual duplication before choosing a continuing case and preserving original evidence.
Intercom
Application concept: Compare an Intercom chat and email request without assuming historical messages should be rewritten into one chronology.
Slack
Application concept: Prepare a Slack handover identifying the surviving ticket and where the earlier source conversation remains.