Notion Self-Relations: Separate Next and Previous Tasks

For a task chain inside one Notion database, create a self-relation with Two-way relation turned on and name the two properties Next task and Previous task. Notion's self-relation instructions explicitly separate the two directions: adding Task B to Task A's Next task makes Task A appear in Task B's Previous task.

Leaving Two-way relation off gives you one property, but it does not guarantee a one-way link. Notion says a one-property self-relation can work in both directions. If “Next task” starts pointing back to the task that came before it, check this setting before assuming that you linked the wrong records.

Choose what the relationship means

I recommend two named directions whenever the distinction changes what someone should do next. “Outline leads to Draft” is different from “Outline is related to Draft.” One field called Related tasks can be enough for an association; a field called Next task should communicate a successor clearly.

This behavior is specific to a database related to itself. Notion documents one-way as the default between two different databases, then explains the different self-relation behavior separately. Do not apply the cross-database rule to a task-to-task relation in the same database.

A self-relation also differs from a self-referencing filter. Here you are connecting task pages to other task pages. A view filter selects which records the view displays; it is not the control that separates Next from Previous. You do not need a template or linked-view dashboard just to record a small task chain.

Create the paired properties

Use a few sample task pages to establish the direction before adding links throughout an existing project. For a new relation:

1. Add a database property and choose Relation.
2. Search for and select the database you are working in. Notion identifies the destination as This database.
3. Turn on Two-way relation.
4. Name one property Next task and its corresponding property Previous task, then finish adding the relation.

These must be the two properties created together by that setting. Creating two independent relations and giving them matching names is not the same setup. The documented reciprocal update belongs to the paired Next and Previous properties.

Inspect a small chain in both directions

In this example, the intended order is Outline → Draft → Review. On Outline, select Draft in Next task. Open Draft and inspect Previous task: it should show Outline under the documented paired-relation behavior. Then select Review in Draft's Next task and inspect Review's Previous task.

The middle task is the useful check: Draft has Outline in Previous and Review in Next. You should not need to maintain a second independent copy of each link. If the reciprocal field stays empty, check that both properties belong to the paired relation and that you selected the intended task page.

If the names communicate the opposite order, resolve that meaning while the example is small. For an existing relation with many links, record the current links and identify the intended predecessors and successors before changing the model. A generic association does not tell you which task was meant to come first.

The empty endpoints have a meaning too: Outline has no predecessor in this example, and Review has no successor. Those empty cells are expected. A broken reciprocal link would instead be a missing Outline in Draft's Previous task after you selected Draft from Outline's Next task.

Map existing associations before replacing them

If an old Related tasks property already contains links, write down the intended order separately before filling a new Next/Previous pair. An association between Outline and Draft cannot tell you whether Outline precedes Draft, follows it, or is simply related work. Do not guess the direction from which page you happen to open first.

For a small existing chain, I would add the new paired relation alongside the old association using the setup above. Enter only the successor links whose meaning you have confirmed, then inspect their corresponding Previous values. Keep the old property until the new order and any views or rules using the old field have been reviewed. Creating a new pair does not automatically migrate the undirected links; you still need to map their direction.

Keep the chain readable

Decide whether each task can have one successor or several. Notion lets a relation select 1 page or No limit. A one-page limit fits a field whose real rule is “one next task.” A workflow with several prerequisites or follow-up tasks needs a different rule. Check the limit on the properties you use rather than treating a many-task list as a linear sequence.

A relation limit sets how many pages can be selected; it does not decide which page is the correct next step. If a task genuinely leads to two others, preserve that branching meaning rather than forcing it into a one-successor field.

Before relying on the chain, inspect its meaning too: no task should point to itself as its own next step, and a sequence such as Outline → Draft → Outline would send the reader around a loop. The links record your choices; they do not establish that the order is sensible.

You can keep both directions in the database while showing only the field a particular view needs. Notion's documented control is the property menu's Hide in view option. Hiding Previous task changes that view's presentation; it does not remove the paired relation or make Next task a one-property self-relation.

Separate task order from date scheduling

Next and Previous describe the links you want people to follow. Naming those properties does not configure automatic date shifting. Notion has a separate Dependencies feature with explicit date-shifting modes, including an option not to shift dates automatically.

If the goal is to move a later task's dates when an earlier task changes, use the dependency date-shifting guide. For a simple reading or handoff order, the paired relation and a clear Next task view are enough.