Merge Duplicate Issues in Linear
Mark the redundant issue as a duplicate of one canonical issue. Linear transfers linked attachments and customer requests through the duplicate workflow, but you should reconcile conflicting descriptions yourself.
Step-by-step guide
Check access and scope
You need access to both issues and agreement about which one should carry the work forward.
Compare the reports
Compare reproduction steps and expected outcomes to confirm one underlying problem.
Choose the canonical issue
Choose the canonical issue with the clearest ownership and useful history.
- Worked example: Two reports describe expired invite links. Keep the engineering investigation as the canonical issue, preserve the second report device details, and distinguish a separate email-delivery failure rather than merging it.
Preserve unique evidence
Copy any unique acceptance criteria or investigation notes into the canonical issue.
Mark the duplicate
Use Mark as duplicate and select the canonical issue. Start from the redundant issue, not the canonical record; the action marks the selected issue as the duplicate.
Inspect the surviving record
Inspect the canonical record and explain the decision to affected subscribers.
Verify the result
The redundant issue points to the canonical record and unique evidence is still accessible.
Common mistakes
Avoid the main failure mode
Similar titles do not prove duplication. Merging distinct user failures can hide scope and distort customer-request counts.
Check the handoff edge case
Choosing the oldest issue automatically can leave the least useful description as the canonical record. Compare evidence and ownership first.
Sources and verification
Based on product documentation checked on 2026-10-24. This is a documentation-based guide, not a hands-on benchmark. Features and availability can change.