Dependent Tasks in a Notion Task Database (aka Master/Sub-task or Parent/Child Tasks)

Dependent tasks in Notion’s task database let action items run in a strict sequence—without forcing every task in the chain to carry its own due date. In this system, only the “head” task in a dependency chain has a due date; each follow-on task waits for the one before it to be checked off, then automatically becomes the next scheduled step. That design matters because it prevents the common failure mode of traditional task lists: rescheduling cascades. If the first task slips, the rest of the chain “rolls” with it, keeping the workflow intact instead of turning into a tangle of independent, floating due dates.

The setup relies on two linked properties inside the same Notion database: a “following” relation and a “next in line” relation. The “dependent tasks” view is filtered to show only items where the “following” field is not empty—meaning the task depends on another task. In practice, a chain looks like this: one task follows a prior task, and each task can point to the next task behind it. When a task is completed, the system surfaces the next item in the sequence, and that next item can then receive a due date and priority at the moment it becomes active. The priority field functions as a timing cue: it carries more weight when a due date is near, and acts more like a placeholder when the due date is farther out.

A key operational detail is how the chain is managed. The first task in the chain is not shown in the dependent-tasks view because it isn’t following anything; it already has its due date and priority. Once it’s checked off, the next-in-line task moves up to become the new head of the chain, and the user assigns its due date and priority. This continues until the final task—identified by having no “next in line”—is completed.

The transcript also addresses why this approach is hard to replicate in many task apps. Most do not support true dependency sequencing where tasks advance automatically based on completion. Notion’s relational fields make it possible to build that structure within a single action-items database.

To create the system from scratch, the workflow starts by adding a relation property to the same database. The crucial choice is to create a new property with two-way syncing (“sync both ways”), which results in two linked fields: one for “following” (what the task depends on) and one for “next in line” (what comes after it). After setting the “following” link for each task in the chain, the reverse “next in line” link populates automatically. The user then clears due dates for dependent tasks so only the active head task carries scheduling responsibility. Finally, the dependent-tasks view is adjusted to filter on the correct “following” field and manually sorted so the “next in line” order matches the intended row sequence.

Overall, the dependency chain turns a task list into an ordered workflow: rescheduling becomes a single change at the front of the chain, while the rest of the sequence stays coherent until completion.