# Subtasks

Subtasks in Super Productivity let you break a task into smaller steps while keeping everything linked: each subtask is a real task with its own title, time tracking, and completion state, but it belongs to a parent task. The app maintains a clear parent-child relationship so you can expand and collapse the hierarchy, see aggregated progress (for example remaining time) on the parent, and move or complete subtasks independently. Understanding how subtasks are modeled, what limits apply, and how completion and movement work helps you use them effectively in projects, tags, and the Today View.

For how to add, reorder, convert, and manage subtasks in the UI, see [[2.04-Manage-Subtasks]]. For how the parent and subtask links fit into the task model, see [[4.09-Task-Attributes]].

## How Subtasks Are Modeled

Subtasks are **separate tasks** linked to a parent in both directions. They are not just labels or lines inside a parent task; each subtask has its own ID, project, time spent, notes, and completion status, like any other task. The difference is the relationship:

- **The subtask (child)** stores a reference to its parent. That link is what makes it a subtask instead of a top-level task.
- **The parent task** stores an ordered list of its subtask IDs. The order in that list is the order you see when you expand the parent.

Because both sides of the relationship are stored, the app can quickly show a parent’s subtask list, update the parent when you complete or move subtasks, and keep the hierarchy consistent when you reorganize. When you add a subtask, move one to another parent, or delete a parent, the app updates both the child’s parent reference and the parent’s subtask list so they always match.

Subtasks can themselves have subtasks (nesting): a task can be both a parent and a child. The same two-way link applies at each level. In practice, very deep nesting can be harder to work with in the UI and in some workflows (for example markdown-based sync) deeper levels may be treated differently; the app is designed so that one or two levels of subtasks are the common case.

## Limitations for Subtasks

Not every task can be turned into a subtask, and some behaviors are constrained so the model stays consistent.

### Tasks That Cannot Be Converted to Subtasks

Two kinds of tasks **cannot** be converted into subtasks:

- **Repeating tasks** — Tasks that recur on a schedule (for example daily or weekly) cannot be made subtasks of another task. See [[4.13-Repeating-Tasks]]. The repeat rule applies to a single task; nesting would conflict with that.
- **Issue-linked tasks** — Tasks that are linked to an external issue (for example Jira or GitHub) cannot be made subtasks. The issue link is a one-to-one relationship between a task and an issue; the app does not support issue-linked subtasks in the same way.

If you try to convert such a task to a subtask (for example by indenting it in a markdown-based workflow), the app will warn you and leave the task as a top-level task. You can still create normal subtasks under a parent and use repeating or issue-linked tasks alongside them as separate tasks.

### Depth and Nesting in Markdown-Based Workflows

When you use a markdown-based workflow (for example the sync-md plugin) that converts indentation into parent-child structure, depth is determined by indentation level. Very deep indentation may be interpreted as note content or a different level of nesting rather than as additional subtask levels. If you rely on markdown import/export, it helps to keep nesting to one or two levels so structure is preserved as you expect.

### Inheritance and Consistency When Moving or Duplicating

- **Project inheritance** — Every task, including every subtask, belongs to exactly one project. When you **move a subtask to a different parent**, the subtask inherits the **new parent’s project**. That keeps the subtask in the correct project without you having to change project manually. If you move it back to another parent in a different project, it will inherit that parent’s project in turn.
- **Duplication** — When you **duplicate a task that has subtasks**, the app duplicates the **entire hierarchy**: the parent and all its subtasks, with new IDs and the same parent-child links. The duplicated subtasks stay under the duplicated parent, so you get a full copy of the structure.

## Completion Behavior

How completion works for parents and subtasks affects how you track progress and what happens when you delete or archive.

### Individual Completion

Subtasks can be **marked complete on their own**. You can complete subtasks before or after the parent: for example, you might finish all subtasks and then mark the parent done, or mark the parent done and leave a few subtasks open for later. The app does not force a fixed order. The parent’s completion state is separate; often the parent is considered “done” when all subtasks are done, but you can override that and complete the parent earlier if you want. Time tracking and remaining-time aggregation (estimate minus time spent) work per subtask and are rolled up to the parent from incomplete subtasks, so the parent’s “remaining work” reflects the sum of what is left on its subtasks.

### Cascade Deletion

When you **delete a parent task**, the app **deletes all its subtasks** as well. You are not prompted to delete them one by one; the parent and its children are removed together. That avoids leaving orphaned subtasks and keeps the task list consistent. If you only want to remove the parent but keep the work, you can move the subtasks to another parent (or convert them to top-level tasks, if your workflow supports that) before deleting the parent.

### Tags and Parent-Child in Tag Views

Tag views (see [[4.07-Tag-View]]) show tasks that have a given tag. To avoid showing the same work twice and to keep the list manageable, when you **add a subtask to a tag**, the app **removes the parent from that tag**. So the tag view shows either the parent or its subtasks in that tag, not both. That way you see one level of tasks in the tag and avoid duplicate or confusing entries. If you want both parent and subtasks in a tag, that pattern is not supported; the app enforces “one level” in tag views for consistency.

## Movement and Reorganization

You can **move a subtask to another parent** (or make it a top-level task by removing its parent). When you do:

- The **old parent’s subtask list** is updated: the moved subtask is removed from it.
- The **new parent’s subtask list** is updated: the moved subtask is added to it (in the position you chose, if the UI allows).
- The **subtask’s parent reference** is updated to the new parent.
- The **subtask’s project** is set to the new parent’s project, as described above.

These updates happen together so that after the move, the hierarchy is consistent: no subtask appears in two parents’ lists, and every subtask points to exactly one parent. Reordering subtasks within the same parent only changes the parent’s subtask list order; it does not change parent references or projects.

## Where Subtasks Appear

Subtasks appear **under their parent** in task lists: in the project view, tag view, Today View, and similar places. You can typically expand and collapse the parent to show or hide its subtasks. In the task detail panel, when you open a parent task you can see and edit its subtask list and open individual subtasks. Parent and subtask attributes (including time estimates and time spent) are used by the [[4.04-Schedule-View]] and [[4.08-Time-Estimates]] so that the parent’s remaining work and the timeline reflect the sum of its subtasks where applicable.

## Related

- [[2.04-Manage-Subtasks]] — How to add, reorder, convert, and manage subtasks
- [[4.09-Task-Attributes]] — How parent and subtask links fit into the task model
- [[4.06-Project-View]] — How projects organize tasks (subtasks inherit project from parent when moved)
- [[4.07-Tag-View]] — How tags work (parent removed from tag when subtask is added to same tag)
- [[4.08-Time-Estimates]] — How parent remaining time is aggregated from subtasks
- [[2.07-Manage-Task-Integrations]] — Issue-linked tasks cannot be converted to subtasks
