Sub-Tasks in Notion: The Ultimate Guide

Notion task lists can support true subtasks—complete with nested display, default subtask creation, and reliable sorting—by combining a self-referential relation, a template-driven linked database, and a set of formula/rollup properties that enforce parent-child ordering. The payoff is practical: subtasks can be checked off, assigned due dates, and shown directly under their parent task even when those subtasks are due earlier than the parent.

The setup starts with a self-relation inside a task database. A new relation property (e.g., “subtasks”) is created that links the database to itself, then split into two roles: “parent task” for the parent reference and “subtasks” for the child reference. Once that relationship exists, creating a task and then setting its “parent task” field automatically makes it behave like a subtask. A small formula tweak to the task’s “state” display adds a right-arrow indicator when “parent task” is not empty, visually distinguishing subtasks from top-level tasks.

Next comes the template that lets users add subtasks from within a specific task page. A template (e.g., “task with subtasks”) inserts a linked database filtered to show only rows where “parent task contains” the template instance’s name. This relies on self-referential filters: when the template is instantiated, the filter updates to the new task’s name, so the linked list automatically becomes the correct subtask list. With that in place, subtasks appear under the parent task and inherit the parent context without manual re-linking.

Default subtasks are trickier. Notion templates can’t spawn brand-new database rows that are independent of the template page, so adding “default subtasks” directly inside the template results in the same rows being reused and marked done in both places. The workaround is to store default subtasks as a synced checklist (outside the template), then copy them into the database when creating a new instance—using an option/alt-drag copy so the subtasks become unique rows with their own parent relations.

The hardest part is sorting. Simple sorting by due date fails because subtasks can share the same due date as other tasks, and subtasks often have due dates earlier than their parent. The solution uses multiple computed fields: a checkbox-like “subseat” flag to identify non-subtasks, a “subseat name” formula that resolves to the parent’s name (or the task’s own name if it’s top-level), a due-date-to-timestamp conversion, and rollups that fetch the parent’s due timestamp for subtasks. Sorting criteria are then layered: first by the parent-based timestamp, then by the parent-resolved name, then by whether a row is a subtask, and finally by the task’s own due date—producing a stable nested order.

To show subtasks inside projects, an additional rollup (“parent project”) pulls the project from the parent task through the parent-task relation. Filters in the project view then use this rollup so subtasks appear under the correct parent task even though they don’t have a direct project relation. The approach is limited to one level of nesting: rollups make deeper sub-subtasks brittle and prone to breakage, so the recommended design is a single subtask layer.