Linear Issue Relations
Work rarely stands alone. One task waits on another, two reports describe the same bug, and a new feature touches an older one. Issue relations record these links so nobody discovers them by surprise.
Types of Relations
Linear supports four relation types. Each type tells a different story about the connection.
| Relation | Meaning | Example |
|---|---|---|
| Blocked by | This issue cannot start until another finishes | Payment screen waits for the payment API |
| Blocking | Other issues wait for this one | The payment API holds up three screens |
| Related | The issues touch the same area | Two bugs in the checkout form |
| Duplicate | Two issues describe the same problem | Two users report the same crash |
Everyday Comparison
Picture a house under construction. Painters cannot start until plasterers finish. Plasterers cannot start until electricians finish wiring. Each trade blocks the next trade. A site manager who sees this chain schedules the workers in the right order. Linear relations give your team the same view.
DEPENDENCY CHAIN
ENG-310 Build payment API
│ blocks
▼
ENG-311 Build payment screen
│ blocks
▼
ENG-312 Test full checkout
ENG-313 Fix typo on checkout page ── related to ── ENG-311
Add a Relation
- Open the issue.
- Open the issue menu or use the command menu.
- Choose Add relation.
- Pick the relation type.
- Search for the other issue and select it.
Linear shows the link on both issues. The other issue updates itself, so you never record the relation twice.
Work With Blocked Issues
A blocked issue carries a visible marker in lists and boards. Filter for blocked issues during planning and ask one question: who can unblock this? Move the blocking issue to the front of the cycle so the waiting work can start.
When the blocking issue closes, the blocked marker clears. The assignee sees the change in their notifications and can start work.
Handle Duplicates
Duplicates waste effort. Two engineers could fix the same bug without knowing. Mark the newer report as a duplicate of the older one. Linear closes the duplicate, links it to the original, and keeps all reports in one history.
Report A (original) ◄── duplicate ── Report B (closed)
│
▼
Engineer fixes once, both reporters get the result
Choose the Right Relation
Use Blocked By for Order
Pick this type when the sequence matters. If task B cannot finish without task A, record the block.
Use Related for Awareness
Pick this type when issues share context but not order. A teammate who opens one issue sees the other and avoids conflicting changes.
Use Duplicate for Cleanup
Pick this type when two reports describe one problem. The close action keeps your backlog honest.
Habits That Keep Relations Useful
- Record blockers the moment you discover them.
- Remove relations that no longer apply.
- Review blocked issues in every planning meeting.
- Avoid circular blocks, where A blocks B and B blocks A. Break the loop by splitting one issue.
Use Relations in Planning Meetings
Open a view that groups issues by blocked status at the start of planning. Ask the team to clear the oldest blockers first. A single unresolved dependency can freeze several developers, so unblocking work often delivers more value than starting new tasks.
Share Context With Other Teams
Relations cross team boundaries. A mobile developer can link an issue to a backend issue owned by another team. The backend team receives a notification and sees the dependency. This visibility replaces long message threads.
Audit Relations Occasionally
Scan a few older issues each month. Remove links to canceled work and confirm that open blocks still apply. Fresh data keeps the signals trustworthy.
