Work Item Relations

Work items rarely exist in isolation. Features depend on infrastructure changes, bugs block releases, and multiple reports often describe the same underlying problem. Relations let you formally link work items to capture these connections, making dependencies visible and workflows more manageable.

Relation types

SetGet supports four types of relations between work items. Each type has a specific meaning and behavior.

Relation type	Direction	Description
Parent-Child	Hierarchical	One item is the parent; others are sub-items. Used for decomposition.
Blocks / Blocked by	Directional	One item prevents another from starting or completing.
Relates to	Bidirectional	Two items are connected but do not depend on each other.
Duplicate of	Directional	One item is a duplicate of another.

Parent-Child

The parent-child relation creates a hierarchy where a large work item (the parent) is broken down into smaller sub-items (the children).

Characteristics:

• A work item can have at most one parent.
• A work item can have unlimited children.
• Children can themselves have children, creating multi-level hierarchies.
• The parent displays an aggregate progress indicator showing how many children are complete.
• In list view, children appear nested and indented under their parent when grouping by parent is enabled.

When to use:

• Breaking an epic into stories
• Splitting a feature into implementation tasks
• Decomposing a bug fix into investigation, fix, and verification steps

Blocks / Blocked by

The blocking relation indicates that one work item must be completed before another can proceed. This creates a dependency chain.

Characteristics:

• "A blocks B" means B cannot proceed until A is completed.
• The inverse is automatically created: "B is blocked by A".
• Blocked items display a warning badge in all layouts.
• The Gantt layout draws dependency arrows between blocking and blocked items.
• Blocking relations do not prevent state changes -- they are advisory, not enforced.

When to use:

• An API endpoint must be built before the frontend can integrate with it.
• A design review must be approved before development starts.
• A database migration must run before the feature can be deployed.

WARNING

Blocking relations are informational. SetGet does not prevent you from completing a blocked item before its blocker is done. The warning badge is a visual reminder for the team.

Relates to

The relates-to relation is a simple bidirectional link between two work items. It means the items are connected in some way but do not have a dependency or hierarchical relationship.

Characteristics:

• Bidirectional: if A relates to B, then B relates to A.
• No hierarchy or dependency is implied.
• Both items show the relation in their detail view.

When to use:

• Two items in different projects that affect the same user flow.
• A frontend change and a documentation update that should be reviewed together.
• Items that share context but are independently actionable.

Duplicate of

The duplicate relation marks one work item as a duplicate of another, indicating that the same work or problem has been reported more than once.

Characteristics:

• Directional: "A is a duplicate of B" means B is the original and A is the duplicate.
• The duplicate item (A) is typically moved to a Cancelled state after the relation is created.
• The original item (B) remains active and carries forward any additional context from the duplicate.

When to use:

• Multiple bug reports describing the same issue.
• Feature requests that overlap with existing planned work.
• Items created by different team members for the same task.

Create a relation

From the detail view

1. Open a work item in detail view or peek panel.
2. Scroll to the Relations section below the description.
3. Click Add Relation.
4. Select the relation type: Parent, Child, Blocks, Blocked by, Relates to, or Duplicate of.
5. Search for the target work item by title or identifier (e.g., WEB-42).
6. Select the target item.
7. The relation is created immediately and appears in both items.

From the properties panel

For parent-child relations specifically:

1. Open a work item.
2. In the properties panel, click Parent to set a parent, or click Sub-items to add children.
3. Search and select the target item.

From the context menu

1. Right-click a work item in any layout.
2. Select Add Relation.
3. Choose the relation type and target item.

Cross-project relations

Relations can link work items across different projects within the same workspace. When searching for a target item, the search includes all projects you have access to. This is especially useful for:

• Linking a backend task in one project to a frontend task in another.
• Connecting a design project item to an engineering project item.
• Marking cross-project duplicates.

View relations

In the detail view

The Relations section displays all relations grouped by type:

Section	Content
Parent	The parent work item (if any), with its state and identifier
Sub-items	List of child work items with state badges and progress
Blocking	Items this work item blocks
Blocked by	Items blocking this work item
Related	Items with a relates-to link
Duplicates	Items marked as duplicates of this one

Each related item shows its identifier, title, state badge, and priority icon. Click any related item to navigate to it.

On the Gantt chart

The Gantt layout visualizes blocking relations as arrows connecting the bars of related items. An arrow from item A to item B means A blocks B. This makes dependency chains visible across the timeline.

Blocked item warnings

When a work item is blocked by another item that is not yet in a Completed or Cancelled state, the blocked item displays a red warning indicator:

• List view -- A small blocked icon appears next to the state badge.
• Kanban card -- A "blocked" banner appears at the top of the card.
• Detail view -- The "Blocked by" section highlights the active blocker in red.

These warnings help the team identify items that cannot proceed and focus on unblocking them.

Remove a relation

1. Open the work item in detail view.
2. In the Relations section, find the relation you want to remove.
3. Click the x or trash icon next to the related item.
4. The relation is removed from both items immediately.

Removing a relation does not affect either work item's state, priority, or other properties. It only removes the link.

TIP

If you remove a parent relation, the child item becomes a standalone top-level item. Its state, assignees, and other properties remain unchanged.

Relation rules and constraints

Rule	Detail
A work item cannot relate to itself	Self-referential relations are not allowed
A work item can have at most one parent	But unlimited children
Duplicate relations should point to the original	The duplicate is typically cancelled
Blocking cycles are allowed but discouraged	A blocks B blocks A is technically possible but creates a deadlock
Cross-project relations are supported	Both items must be in the same workspace
Deleting a work item removes its relations	But does not affect the related items themselves

WARNING

Avoid creating circular blocking chains (A blocks B, B blocks C, C blocks A). While SetGet does not prevent this, it creates an unresolvable dependency loop. The Gantt view will highlight circular dependencies with a warning indicator.

Use cases by relation type

Parent-child decomposition

A common pattern is to create an Epic or Story as a parent, then add Tasks as children:

EPIC: User onboarding redesign
  STORY: New welcome screen
    TASK: Design welcome screen mockups
    TASK: Implement welcome screen UI
    TASK: Write welcome screen copy
  STORY: Email verification flow
    TASK: Update email templates
    TASK: Add verification endpoint
    TASK: Add verification UI

The parent shows aggregate progress -- if 4 of 6 tasks are complete, the Epic shows 67% done.

Blocking dependency chain

Model sequential dependencies to make the critical path visible:

Database migration (blocks) -> API endpoint (blocks) -> Frontend integration (blocks) -> QA verification

The Gantt chart draws arrows along this chain, and any delay in an earlier item shifts the expected start of later items.

Duplicate consolidation

When multiple people report the same issue:

1. Identify the most complete report as the original.
2. Mark others as "Duplicate of" the original.
3. Copy any unique context from the duplicates into the original's description or comments.
4. Cancel the duplicate items.

This keeps the backlog clean while preserving all information.

Cross-project context

When work spans projects:

Project: API
  TASK: Add /export endpoint (relates to) ->

Project: Web
  TASK: Add export button to dashboard

The relates-to link helps both teams stay aware of connected work without creating a dependency.

Best practices

• Use parent-child for decomposition -- Break large items into manageable pieces. Aim for children that can be completed within one cycle.
• Use blocking for real dependencies -- Only mark items as blocking when one truly cannot start until the other finishes. Overusing blocking relations creates noise.
• Use relates-to for context -- When two items are related but independent, a relates-to link is enough. Do not use blocking just because the items are connected.
• Mark duplicates promptly -- Duplicate items waste triage time. When you spot a duplicate, mark it immediately and cancel it.
• Review blocked items in standups -- Blockers are the most actionable relation type. Surface them daily to keep work flowing.
• Keep hierarchies shallow -- Two to three levels of parent-child nesting is usually sufficient. Deeper hierarchies become hard to navigate.
• Use the Gantt view for dependency analysis -- The visual representation of blocking chains makes it easy to spot bottlenecks and critical paths.

Related pages

• Work Item Properties -- Complete property reference
• Gantt Layout -- Visualize dependencies on a timeline
• Dependencies -- Dependency planning across projects
• Bulk Operations -- Manage relations in bulk
• Filters -- Filter by relation status
• Cycles -- Track blocked items within a sprint