What are task dependencies?

Most tasks are not independent. The invoice waits on the timesheet, the launch waits on the review, the review waits on the draft. If your task list treats them as equals, it will keep offering you work you cannot do yet, and you will spend attention rediscovering the same blockers every time you look.

Modeling dependencies fixes that in three ways. First, blocked tasks can be hidden or pushed down, so the list shows only what is actually startable. Second, the chain reveals the critical path: the sequence whose delay delays everything, which tells you which task deserves protection this week. Third, finishing a predecessor unblocks its successors automatically, so the next step surfaces without a review.

Dependencies are also a communication tool in small teams. ‘Blocked by Maria’s design’ says exactly why something is not moving, without a status meeting. The cost is discipline: a dependency that is out of date is worse than none, so dependencies work best in tools that keep them attached to live tasks rather than in a separate plan.

• Only model real blockers. Ask whether you could physically start this before that is done. If yes, it is a preference, not a dependency. Over-linking produces a rigid plan nobody follows.
• Prefer finish-to-start. It is the simplest relationship and covers most cases. Save start-to-start and finish-to-finish for when you truly need them.
• Keep chains short. Long chains hide slack and make one late task ripple through everything. Break big projects into a few parallel tracks.
• Name the blocker when it is a person. If a task waits on someone outside your system, a waiting-for list entry is often clearer than a dependency.
• Look at the chain visually. A Gantt chart turns a list of links into arrows you can read at a glance.
• Watch for cycles. A depends on B depends on A is a modeling error that will stall a project silently. Good tools reject it.
• Combine with prioritization. Sort blocked tasks down and unblocked ones up so the top of your list is always something you can do.

In Fluidwave a task can be blocked by one or more other tasks, and the relationship is stored on the task itself, not in a separate project plan. Dependencies can be added from the task detail or by asking the chat assistant.

The Gantt view draws them as arrows between bars, with day, week and month zoom, so a chain of blockers reads as a timeline. Fluidwave checks for circular dependencies when you add one, so a loop is caught at the moment it would be created rather than discovered as a mysteriously stuck project.

Dependencies feed directly into what the app shows you. Blocked is one of the twelve auto-prioritization criteria, so blocked tasks can fall below anything you can act on. The Active filter goes further and hides work you cannot start along with future-dated and waiting tasks. When a predecessor is completed, its successors become unblocked and rise on their own.

Fluidwave does not do resource leveling or critical-path math across large portfolios; it is built for personal and small-team work. For that scope, dependencies plus Gantt plus auto-prioritization cover what most people actually need: knowing what is startable now. See Fluidwave vs ClickUp if you need heavier project tooling.