ClickUp Dependencies: Blocking vs Waiting On, Made Simple

A misread dependency can turn a client hand-off into a missed launch. A red icon can look like a stop sign, while a yellow one can look like permission to carry on. Read them backwards and a team may promise a launch date before the work is ready.

Prefer to watch? The full walkthrough is on YouTube: https://www.youtube.com/watch?v=eLxR8HgPWiI

What does Blocking vs Waiting On mean in ClickUp?

Blocking and Waiting On are not separate features. They are two ends of the same dependency. The earlier task blocks the later one. From the later task, ClickUp shows that it is waiting on the earlier task, sometimes labelled “blocked by”. Create the relationship once and it appears from both ends.

The List icons show which end you are looking at. A red circle with a minus means this task is holding another task up. A yellow warning triangle means this task is waiting for something else. A task in the middle of a chain can show both.

A linked task is different. It says two tasks are related, but neither waits for the other. A Relationship field has a separate job: connecting records such as clients, projects and invoices. For more on that distinction, see ClickUp Relationships vs Related Items.

When should you use a ClickUp dependency?

Start with the later task and ask: Can this honestly be finished before the other task is done?

If yes, it does not need a dependency. Link the tasks if the connection is useful context. If no, set the later task to wait on the earlier one. The direction matters because the dependency should describe the work that cannot finish yet, not just two tasks that happen to be related.

Use dependencies for hand-offs between people or between your team and a client. They are not a substitute for ordering one person’s own to-do list. List order or a checklist can handle those steps. The point is to show who needs to finish what before someone else can move, so an account manager does not have to chase for a status update and a client is not given a date the team cannot meet.

How to set up ClickUp dependencies for a client hand-off

Use a small client onboarding chain as the model. The same structure works for any work where one task genuinely has to finish before another can.

1. Create the work locations. Create a Space for client delivery, a Folder for the client, and two Lists inside it: Onboarding and Finance. Keeping the Lists in the same Folder also matters if you later save the work as a template.
2. Add the tasks before linking them. In Finance, add “Deposit invoice paid”. In Onboarding, add “Kickoff call”, “Client sends brand assets”, “Homepage first draft”, “Client approves homepage”, “Build remaining pages” and “Launch”. Add the owners and dates your team needs to manage the hand-offs. Add “Brand guidelines” too if you want a related task for reference rather than a dependency.
3. Create the first dependency from the later task. Open “Kickoff call”, go to Relationships, select the plus, choose “This task is blocked by”, then select “Deposit invoice paid”. The kickoff is the later work, so the question is what it is waiting on. The invoice can live in a different List.
4. Add more links from the List view. Add the Dependencies column to the Onboarding List view. On “Client sends brand assets”, add “Kickoff call” as the task it is blocked by. On “Homepage first draft”, add both “Kickoff call” and “Client sends brand assets”. A task can wait on more than one task.
5. Connect the remaining chain in Gantt. Open a Gantt view for the Folder. Drag the connector from the end of “Homepage first draft” to the start of “Client approves homepage”, then connect approval to build and build to launch. The arrow runs from the blocking task to the task that is waiting. The full chain makes the client hand-off visible without opening every task.

How to make a dependency do useful work

A dependency by itself is a link between tasks. Two ClickUp settings and one Automation can make that link more useful.

6. Turn on Dependency Warning. An admin can enable it for the Space in the App Center. If someone tries to close a task that is still waiting on another, ClickUp shows a warning. It does not stop someone starting the task, changing its status or tracking time on it.
7. Turn on Reschedule Dependencies. In the App Center, open Scheduling & Dates and enable Reschedule Dependencies. Make sure “Trigger even when dependencies are closed” is off for this setup. Then move a blocking task in Gantt and check whether the dates on the waiting tasks move with it. This avoids re-dating each task by hand, but it is still worth checking the resulting dates against every blocker.
   As of October 2026, rescheduling moves a waiting task by the same number of days as the change to its blocker. In a test with two blockers, moving one by two days moved the waiting task by two days, not four. A planned buffer does not absorb the delay automatically, so check the full chain rather than assuming the new date is safe.
8. Notify the next owner when work unblocks. In the Onboarding List, open Automations, choose Create, set the trigger to “Task or subtask unblocked”, and choose “Add a comment” as the action. Have the comment mention the assignees, for example: “You’re clear to start. Everything this task was waiting on is done.” When the deposit task moves to Complete, the kickoff unblocks and the account manager gets the comment on the task.

Dependency mistakes that create false confidence

Treating an active status as finished. ClickUp clears a dependency when the blocking task is in a Done status. If “Client Approved” is an active status, the team may treat approval as complete while “Build remaining pages” still shows as waiting. Put the status that genuinely means finished in the Done group. In the tested setup, the default “Complete” Closed status also cleared the waiting icon. The relationship can remain visible in the task’s Relationships section after the task is no longer actively blocking, so the visible link alone does not mean the hand-off is still waiting.

Saving only one List as a template. A List template keeps dependencies between tasks inside that template, but drops a dependency that points to another List. If Onboarding depends on the payment task in Finance, save the whole client Folder as the template so both Lists and their hand-off are together.

Linking every task in the process. More links do not make the timeline more accurate. If a task can be finished independently, keep it independent or use a linked task for context. Reserve dependencies for a real hand-off that changes who can start next.

How to check the setup before relying on it

Try the chain with a small set of test tasks before using it for client dates. Link the later task as blocked by the earlier one, add dates, and move the blocker two days in Gantt. Check which waiting tasks moved and compare each new date with all of its blockers. Then test the “Task or subtask unblocked” Automation by moving the blocker to Complete and checking that the comment appears on the waiting task.

That test also catches the status trap: if the blocker stays in an active status, the waiting task will not unblock. Once the sequence behaves as expected, use dependencies for the hand-offs that affect your client timeline, not for every item on the to-do list.

If client hand-offs keep slipping and you want help finding the cause, book a free call with Hina.