Hierarchy, Links, and Dependencies

Work items can be connected to each other in three distinct ways. Each serves a different purpose, and choosing the right one keeps plans readable and reporting meaningful.

Relationship	What it means	Typical use
Parent–child	"This item is part of that item"	Containment — an Epic contains Issues, an Issue contains Tasks
Link	"This item is related to that item"	Qualitative relationships like blocks or duplicates
Dependency	"This item's schedule depends on that item's schedule"	Scheduling calculations with lag and constraint type

Parent–child hierarchy

Each work item can have a single parent work item, forming a tree. The parent–child relationship expresses containment: the child is a part of the parent.

The type hierarchy controls which types can be children of which:

Epic
  └── Issue
        ├── Task
        │     └── Sub-task
        └── Bug
              └── Sub-task

• An Epic can contain Issues
• An Issue can contain Tasks, Bugs, and Sub-tasks
• A Task or Bug can contain Sub-tasks
• A Sub-task cannot contain children

Attempting to create a work item with an invalid parent type (for example, nesting an Epic under a Task) is rejected. Cycles are also prevented — a work item cannot end up as its own ancestor.

When a child has a parent that belongs to a project, the child inherits that project automatically. This keeps hierarchies consistent within a project.

Links

A link is a named relationship between two work items. Unlike parent–child, links are not containment and do not affect scheduling. They describe how two items relate to each other.

The supported link types are:

Link type	Meaning
Blocks	The target cannot start until the source completes
Relates to	Informational relationship — the items are connected
Duplicates	The target is a duplicate of the source

Links are directional: they record a source and a target, so "A blocks B" is distinct from "B blocks A." The same pair of items can have multiple links of different types.

Links cross project boundaries freely. A work item in one project can block, relate to, or duplicate an item in another project within the same tenant.

Dependencies

A dependency is a scheduling relationship between two work items. Dependencies drive schedule calculations — they determine when an item can start or finish based on another item's dates.

Each dependency has a type drawn from standard project scheduling:

Dependency type	Code	Meaning
Finish to Start	FS	Successor starts after predecessor finishes (most common)
Start to Start	SS	Successor starts when predecessor starts
Finish to Finish	FF	Successor finishes when predecessor finishes
Start to Finish	SF	Successor finishes when predecessor starts

Dependencies also carry:

• Lag — a time offset applied to the dependency (for example, "start 2 days after the predecessor finishes")
• Hard constraint flag — whether the dependency is enforced strictly or advisory

Like links, dependencies can span project boundaries within the same tenant, and cycle detection prevents a dependency graph from containing loops.

Choosing the right relationship

Use the relationship that matches the meaning you want to record:

• Use parent–child when one item is a component of another. The child belongs inside the parent's scope.
• Use a link when you need to express a qualitative relationship — something blocks, duplicates, or relates to something else — without implying containment or schedule coupling.
• Use a dependency when scheduling logic should flow between two items. If you want the system to calculate when work can start or finish based on other items, dependencies are the right tool.

The three relationships can coexist on the same pair of items. A child Task under an Epic can also have a dependency on another Task in a different Epic, and a link marking it as a duplicate of a third item.