By 
If changing a Notion task’s date does not move its dependent task, check More settings → Dependencies in the source database. The selected automatic date-shifting mode determines whether dates move: Do not automatically shift leaves them unchanged, while Shift only when dates overlap can leave the next task in place even after its blocker moves.
I’d check that mode before rebuilding the timeline. A visible relationship doesn’t mean the schedule follows every upstream change; that’s a separate choice, and the mode is where you make it. First identify the task pair, then compare what happened with the rule you selected.
Identify the task that should drive the shift
Open the two task pages. Name them A and B for this check: A blocks B, so A is the task whose changed dates should influence B. Inspect the dependency relationship in your database and confirm that it connects these exact pages in that direction. Two neighboring timeline bars do not establish a dependency.
Do not confuse a subtask with a dependent task. Notion describes sub-items as smaller pieces of work and dependencies as linear task relationships. Nesting “Review proposal” under “Prepare proposal” describes a breakdown of work; you still need to check the scheduling relationship you intend to use.
Record A’s and B’s original dates, the date you changed, and the resulting dates. If the database has several date properties, write down their names too. A due date, an internal review date, and a date shown on a timeline can represent different commitments. Inspect the actual property values rather than judging the result only from the bars’ positions.
Check this in the database that supplies the project view. A linked view can show the same records with different presentation settings, while a duplicated tracker contains different pages. The guide to which linked database edits reach the original helps identify the source before you change it.
Check which dates the timeline displays
If you have several date properties, open the timeline’s settings and select Layout → Show timeline by. Notion lets you choose the property plotted on the timeline, including a range in one property or separate start and end properties.
Compare that selection with the date you edited and the values recorded on A and B. For example, a timeline showing “Work period” is not a reliable way to inspect a change to “Client deadline” unless those values are deliberately coordinated. Show timeline by chooses the display dates; it is not itself the automatic date-shifting mode.
Read the three shift modes literally
These are the three behaviors Notion documents. Choose the one that matches your scheduling rule, rather than switching settings until something moves.
| Mode | Expected behavior | Choose it when |
|---|---|---|
| Shift only when dates overlap | Tasks shift when their dates start to overlap. The gap between tasks may shrink. | You want to handle collisions while allowing existing gaps to change. |
| Shift & maintain time between items | When the blocker’s due date moves forward, the dependent due date follows by the same interval in Notion’s example. | The time between tasks is part of the plan. |
| Do not automatically shift | Dependency due dates do not move automatically. | Someone should decide or approve each date change. |
An existing gap can shrink without moving the next task
With Shift only when dates overlap, changing A does not require B to move if their dates still do not overlap. For example, A can move later into an existing gap while B stays put. That is consistent with Notion’s statement that tasks shift only when their dates start to overlap, and the distance between them may decrease.
Inspect both tasks’ date ranges before you call this a failure. Skip this mode if your requirement is “move B whenever A moves, keeping our review buffer.” That requirement points to Shift & maintain time between items.
Preserving the interval moves the dependent date
Notion gives a clear example for Shift & maintain time between items: if A blocks B and A’s due date moves forward one week, B’s due date also moves forward one week. Use this as the basic rule for comparing your task pair, then check weekend handling separately.
Here is the same rule with example dates. A is Draft proposal, B is Review proposal, and A blocks B. The selected mode is Shift & maintain time between items, with Avoid weekends off. Compare these due dates:
| Task | Original due date | Forward-change example |
|---|---|---|
| A: Draft proposal | 12 Oct 2026 | You change it to 19 Oct 2026: +7 days. |
| B: Review proposal | 15 Oct 2026 | The documented one-week rule points to 22 Oct 2026: +7 days. |
The three-day interval between the due dates remains three days. This example applies Notion's stated forward-shift rule; it does not cover backward moves, overlapping ranges, weekend adjustments, or a whole dependency chain. For a real pair, read the date properties on the pages after the change. If B still reads 15 Oct under these simple conditions, return to the relationship direction and mode before adding another scheduling operation.
I would choose this mode for a review interval that must move with the draft deadline. I would keep a fixed client launch date under manual control if moving it requires agreement. Those are different scheduling commitments; one setting should not quietly turn an approved deadline into a floating date.
Manual mode keeps date decisions manual
Under Do not automatically shift, due dates are never automatically shifted by the dependency feature. The relationship still shows the order of the tasks. If you picked this mode, unchanged dates are the expected result. Before you turn automatic shifting on, decide whether this workflow should let dates move on their own.
Check weekend handling before comparing the gap
The Avoid weekends setting lets you prevent shifted items from starting or ending on weekends. Note its state alongside the mode when you compare dates.
This rule covers shifted endpoints. It doesn’t promise to move every existing task in the database off a weekend. If a shifted date would otherwise land on Saturday or Sunday, don’t assume the interval you meant to keep still equals a simple fixed number of calendar days. The Help page doesn’t describe a complete adjustment algorithm for every arrangement of dates, so inspect the resulting start and end values before you accept the schedule.
Change the setting and check one task pair
Before changing a shared tracker, agree on which dates are allowed to move. Note the existing mode and task dates so you can compare the result. The setting controls scheduling behavior; it does not decide whether a new client commitment is acceptable.
- Open the settings menu at the top of the source database.
- Under Database settings, select More settings → Dependencies.
- Select the intended automatic date-shifting option.
- Set Avoid weekends to match the project’s scheduling rule.
If dependencies have not been enabled, the same menu includes Turn on dependencies; enable the feature and establish the intended relationship before expecting a dependent task to follow.
For your own check, use two noncritical task pages with populated dates and one clear blocking relationship. Record the mode and weekend setting, then make a controlled forward change to A. Inspect both pages’ dates and compare B’s response with the selected mode. Start with one pair so you can distinguish a mode issue from a more complicated chain.
If the result still does not match
Keep a concise record for support: the source database, A and B’s page links, the direction of the dependency, date-property names, before-and-after values, selected shift mode, and Avoid weekends state. Include any other tasks connected to that pair. If you cannot edit the relevant date or settings, record that separately rather than treating a permission problem as a failed shift.
If the simple pair behaves as intended but the project still looks wrong, compare the remaining tasks one at a time and check which date property the timeline displays. The small pair’s result doesn’t prove that every linked task runs in the same direction, gets the same mode-dependent outcome, or allows the same date change. Before you restore your intended dates, check who else relies on the schedule; blindly undoing a shared timeline change can create another discrepancy.
A mode check tells you what should happen; it can’t pin down the cause of every unexpected result. While the discrepancy is unexplained, don’t delete task pages or add a second date-writing workflow. Either one makes it harder to tell which operation changed a deadline.
If the relationship itself is unclear, return to the client project tracker’s task structure and decide which task waits for which. Date shifting only helps once that planning decision is explicit.
