Asana dependencies: why are task dates not moving?
Asana dates not moving? Check dependency links, due dates, completed tasks, plan access and buffer settings with a small schedule test.
In this guide
A dependency link is only part of the setup
Asana’s auto-shifting documentation lists several conditions: the tasks must be linked as dependencies, have due dates, remain incomplete and use an appropriate dependency date-shifting setting. The feature is documented for Starter and higher current tiers, alongside eligible legacy plans.
Begin with one blocking task and one dependent task. Record the exact date change you expected. A line between tasks describes a relationship; it does not prove that every scheduling preference or required date has been configured.
Check the buffer setting before editing the whole plan
Asana distinguishes maintaining the gap between tasks, consuming that gap and ignoring it. Its documentation also distinguishes moving all tasks in a chain from moving downstream tasks. Completed tasks are excluded from automatic shifting, and subtasks are not automatically covered merely because they sit under a parent.
Read the actual project setting before changing dates again. Capture the predecessor, successor and their dates so the schedule owner can reproduce the question. Repeatedly dragging several tasks makes it harder to tell which change caused the final result.
Work through a small scheduling example
Imagine an illustrative design project with three stages: draft, review and release. Draft work is due on Monday, review on Wednesday and release on Friday. The project owner wants to move the draft to Tuesday. First ask whether review must move, whether a gap may be consumed and whether the release date is a fixed commitment.
Those are business decisions before they are settings. A tool that shifts the entire chain could be correct for a flexible internal plan and wrong for an already announced launch. Write the intended result before trying the change in an authorised test project.
Keep the test small and observable
| Check | Record before the change | Record after the change |
|---|---|---|
| Task relationship | Named blocker and dependent | Relationship still correct |
| Schedule | Both due dates and relevant starts | Actual new dates |
| Preference | Chosen buffer behaviour | Observed shift |
| Completion | Open or completed state | Whether completed work was left alone |
Leave the after-change column blank until observed. Run a single date change at a time. If the schedule includes subtasks, add them explicitly to the acceptance brief rather than assuming the parent relationship covers them.
Escalate with the useful details
If the result differs from the intended behaviour, give the project administrator the plan, view, dependency setting, task states, dates and exact operation. Distinguish a missing entitlement from a scheduling rule that is working as configured. Include the smallest harmless example that shows the problem.
Use the Asana profile for the broader plan discussion and the project-management trial guide when evaluating a new workflow. Treat date movement as one acceptance case, alongside ownership, handovers and the way the team approves changes to a committed deadline.
Frequently asked questions
Does an Asana dependency automatically move every linked date?
Not necessarily. Check dates, task completion, the selected dependency shifting setting and the feature entitlement for the actual project.
Do completed Asana tasks move with automatic date shifting?
Asana’s documented auto-shifting requirements exclude completed tasks.
Do Asana subtasks inherit dependency date shifting automatically?
The documentation says the functionality does not apply to subtasks by default. Define the required dependencies explicitly and test the intended chain.
Put the guide into practice
Explore project management tools, then compare your shortlist.
Explore the category →