For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/tasks/subtasks-and-dependencies.md.
Subtasks and dependencies
Break large work into subtasks, and sequence work that genuinely blocks other work.
Two different tools that people often confuse:
- Subtasks break one piece of work into smaller pieces.
- Dependencies say one piece of work cannot start until another finishes.
#Subtasks
A subtask is a real task — its own assignee, dates, estimate and status — that belongs to a parent.
Use one when a piece of the work needs to be owned or scheduled separately. If it just needs ticking off, use a checklist instead.
"Write migration script" — someone owns it, it takes a day, it has a due date.
"Update the changelog" — thirty seconds, same person, no scheduling.
Closing a parent does not close its subtasks
They stay open and keep appearing in filters and reports. Close them first, or from the parent's subtask list.
#How deep
One level. A subtask of a subtask means the parent should have been a milestone or an epic, not a task.
#Dependencies
A dependency records that work must happen in order. The Gantt chart uses them to shift dates when something slips, and on Premium to calculate the critical path.
| Type | Meaning |
|---|---|
| Blocks | This task must finish before the other can start |
| Blocked by | This task cannot start until the other finishes |
#Use them sparingly
Over-linking makes the Gantt useless
Every dependency constrains the schedule. A plan with hundreds of them becomes brittle — one slipped task cascades into a redrawn timeline nobody trusts, and the team stops looking at it.
Record a dependency when it is a genuine hard constraint: the API must exist before the client can call it. Do not record soft preferences about what people would rather do first — that is what priority and sprint planning are for.
"Database migration blocks API rollout." Physically true.
"We'd rather do the design first." That is sequencing preference — use priority.
#Cross-project dependencies
The ones that actually cause trouble are between teams. Record those explicitly: they are exactly the constraints that surprise people, because neither team sees the other's board.
On Premium, programs surface cross-project dependencies in one view.
#Which to use
Big task, several people
Subtasks. Each person owns one.
Sequential work, same person
Usually neither — one task with a checklist. Add subtasks only if the pieces need separate dates.
Work spanning teams in order
Dependencies. The Gantt then shows the knock-on effect when something slips.
Work spanning sprints
Split into separate tasks per sprint, linked by a dependency. A task that straddles sprints breaks velocity.