compare
Dependencies get added to a project in an afternoon. A month later the plan has drifted, one task slipped by a week, and nothing downstream moved. The links are all still there in the task panes, so the natural conclusion is that dependencies do not work. The actual explanation is narrower and more useful: linking two tasks and shifting their dates are two separate features, and the second one is switched off in most projects unless somebody turned it on.
That distinction is worth getting straight before adding another link. What follows is what a dependency changes, what it does not touch, and which setting decides the difference.
Asana originally offered a single relationship, finish to start. Three more have since been added, so there are now four. In every case one task is the precedent and the other is the dependent, and the marking is done from the dependent side as blocked by, or from the precedent side as blocking.
| Type | The claim | A case where it fits |
|---|---|---|
| Finish to start (FS) | Task B cannot start until Task A is complete | Editing cannot begin until the draft is finished |
| Finish to finish (FF) | Task B cannot finish until Task A is complete | The design phase cannot close until the research interviews are done |
| Start to start (SS) | Task B cannot start before Task A starts | The social post is not drafted until the web page build has begun |
| Start to finish (SF) | Task B must start before Task A can complete | One operator's shift does not end until the replacement's shift begins |
Finish to start is the default at creation, and it is the one applied when nobody chooses. The type can be changed afterwards, which matters because the wrong type will still draw a line on the timeline and still look correct in the task pane while shifting the wrong date.
Two of these four are the ones teams commonly get wrong. Finish to finish suits a parent task that cannot be closed while its children are open, which is exactly the shape of most delivery checklists. Start to start suits work that has to run in parallel with a shared trigger, which is the shape of a launch. Both of those relationships are frequently modelled as finish to start, which sequences work that was meant to overlap and pushes the plan out for no reason.
This is the part that explains most confusion about dependencies. Each type has its own pair of relevant dates, and those are the only dates the shifting logic looks at.
| Type | Date read on the precedent | Date changed on the dependent |
|---|---|---|
| Finish to start | Due date | Start date |
| Finish to finish | Due date | Due date |
| Start to start | Start date | Start date |
| Start to finish | Start date | Due date |
Read the first row against a common setup. A finish to start dependency reads the precedent's due date and moves the dependent's start date. If the dependent task has only a due date and no start date, there is no start date to move. This is why teams who set due dates alone and skip start dates often see nothing happen when an upstream task slips: the field the feature would have changed does not exist on the card.
The requirement is stated plainly in the documentation. Both tasks need due dates set, and the behaviour also works when a start date and a due date are both present. In practice, giving every task on a dependency chain both a start and a due date is the difference between a chain that reflows and a chain that is decoration.
Dates do not move because a link exists. They move because a project-level setting says they should. There are three options, reached from the drop-down next to the project name under Manage dependencies.
None is the default setting for dependency date shifting, and only new projects with a Gantt tab are set to consume buffer. For a project created some time ago, or one without a Gantt tab, the likely state is that no shifting is configured at all. Nothing in the task pane indicates this, which is why the links appear to be inert.
Four other conditions have to hold for shifting to happen. The tasks involved must not be complete, since finished tasks are left alone. Both tasks need dates, as above. The setting has to be maintain or consume buffer. And under consume buffer specifically, the change has to create an actual overlap, so pushing a dependent task later when there is already slack in front of it does nothing.
The behaviour is available in list, board, calendar, timeline and Gantt views. Outside Timeline and Gantt, changing a date on a task with dependencies opens a confirmation showing every resulting change, which can be edited before saving. Weekends are skipped automatically, and that can be changed in project settings through the Customize menu.
Three gaps account for most of the surprise, and all three are documented rather than hidden.
Subtasks are excluded by default. Auto-shifting does not apply to subtasks unless a subtask has been explicitly marked as dependent on its parent. Teams who keep the real work in subtasks under a handful of parent cards are therefore running dependencies over the summary layer only, while the dates people work to sit one level down and never move.
Resource conflicts are not modelled. A dependency describes a relationship between two pieces of work, not between two claims on the same person. The four types cover logical sequence. They say nothing about the case where two unrelated tasks both need the one designer in the same week, which is the most common cause of a small team's plan slipping. That belongs to workload and capacity views, not to dependency links, and on Asana resource management sits on the Advanced plan rather than Starter.
The free plan has none of this. Task dependencies, dependency types and auto-shifting dates are all listed as available on Starter, Advanced, Enterprise and Enterprise+, plus the legacy Premium, Business and Legacy Enterprise tiers. The Personal plan, which is capped at two users, does not include them. Anyone evaluating dependency handling on a free account is evaluating a different product, which is worth knowing before drawing conclusions from a trial. Comparing where each tool draws that line is often more informative than comparing the feature lists themselves, and a plan by plan comparison makes the boundary easier to see than two pricing pages side by side.
Notifications are narrower than most people assume, and knowing the exact rule prevents a lot of missed handoffs.
The assignee of the dependent task is notified in two situations: when the precedent task is marked complete, and when the precedent task's due date is changed or removed. That is the list. The notification goes to the assignee of the dependent task, so an unassigned dependent task notifies nobody, and a task chain that runs through an unassigned card has a silent link in it.
The second rule is the one that catches teams out. When a task is dependent on several precedents, only one notification is sent, and it is sent when all of them are complete. Finishing three of four upstream tasks produces silence. For a fan-in step that waits on four contributors, the person waiting has no signal about progress until the last piece lands.
The practical response is to stop treating notifications as the handoff mechanism for anything that matters and put the state somewhere visible instead. A list view can carry Blocked by and Blocking as separate columns, added through the Add field button in the column header, which turns the dependency graph into something scannable rather than something that has to be opened card by card.
A few habits separate a dependency map that survives a quarter from one that gets abandoned.
Link the tasks people actually work on, not the summary cards above them. If the real work lives in subtasks, either promote those subtasks to tasks or mark them dependent on the parent explicitly, because otherwise the shifting logic has nothing to act on at the level that matters.
Give every task in a chain both a start date and a due date. This is the single highest-return change, and it takes one pass through the project.
Choose the type deliberately on anything that overlaps. The default is finish to start, and accepting it on work that was meant to run in parallel is how a plan gets longer than the work requires.
Draw the chain on a timeline rather than in task panes. On Timeline, hovering a task exposes a connector that can be dragged to another task, which makes the whole sequence visible while it is being built. Mistakes in sequencing are obvious in that view and nearly invisible in a list of task details.
Keep the count low. A single task can be dependent on many tasks and can block many others, and the documentation confirms both directions work. The limit is not technical, it is comprehension. Once a project has more links than anyone can hold in their head, the map stops being used for decisions and becomes something people work around.
Not every reason one task waits on another is a sequencing problem. Dependencies of the logical kind, where one task's output is the next task's input, are exactly what these links model. Three other kinds are common and none of them fit.
Resource dependencies, where the constraint is a person's available hours rather than an ordering of work, need a view of who is loaded when. Preferential dependencies, like a final review a team has chosen to add, are real but negotiable, and encoding them as hard links makes a schedule look more rigid than it is. External dependencies, such as a client approval or a vendor delivery, sit outside the board entirely, and the useful record is a date and an owner for chasing it rather than a link to a task nobody on the team can complete.
The distinction matters for tool choice. A team whose real problem is sequence wants dependency types and reflowing dates. A team whose real problem is that four projects share the same three people wants a schedule view and a workload view side by side, and needs both to be available without an upgrade rather than parked on a higher tier.
Open one project that already has dependencies in it and check the Manage dependencies setting. If it reads none, the links in that project have never moved a date, and turning on maintain or consume buffer will change more than adding further links would. Then add start dates to every task in the longest chain, since the shifting logic reads the precedent's due date and writes the dependent's start date, and a missing start date is a dead link. If a project needs a schedule view, a workload view and the conversation about slippage in the same place without three plans to compare, Pinateca includes Gantt, resource and discussion boards on the free tier for up to five people and ten boards.
Most often because date shifting is not switched on for that project. None is the default setting, and only new projects with a Gantt tab start on consume buffer. Check Manage dependencies from the drop-down next to the project name. The other common cause is a missing start date on the dependent task, since a finish to start dependency writes to that field.
No. Dependencies, dependency types and auto-shifting dates are listed for Starter, Advanced, Enterprise and Enterprise+, along with the legacy Premium, Business and Legacy Enterprise tiers. The free Personal plan, which allows two users, does not include them.
Yes. A task can be marked as blocked by or blocking a task that lives in another project, and the split Blocked by and Blocking columns in list view are described as making those cross-project relationships easier to see. The relationship is between the two tasks, not between the projects.
Not by default. Auto-shifting dates does not affect subtasks unless a subtask has been explicitly marked as dependent on its parent task. For teams that keep detailed work in subtasks, this is the most common reason a dependency chain appears to do nothing.
Only when all of them finish. The assignee of the dependent task receives one notification once every precedent task is complete, plus a notification when a precedent task's due date is changed or removed. Partial progress upstream produces no notification, which is why a shared view of what is blocking what tends to be more reliable than waiting for an alert.