Feature Requests

There is currently no reliable way to define a fixed “Project Start Date” in ClickUp that can be used as a reference point for formulas, automations, and AI. This is a core gap in project planning. We can't calculate project-specific week numbers for tasks (e.g. "This is Week 3 of the project"). The existing “Week” value in Calendar or Gantt views is based on the week of the year, which is not useful for internal project timelines that start at different times. We can’t configure task start/end dates relative to a project start point (e.g. "Start this task 10 days after project kickoff" or "Trigger 3 days before project end"). This is essential for automating templates and milestone plans. Right now, we’re forced to use hacky automations, patchy formulas, or manual date input — which defeats the purpose of having a project management platform. Even recent improvements like calculating end dates from duration are partial fixes that still don’t solve the root problem. Please give us a static project reference date — ideally using the List Start Date — that is: Globally accessible in formulas Usable in automations and templates Referenceable by AI agents Able to drive dynamic date logic across tasks This is Project Management 101 — every professional PM tool anchors schedules to a static start or end date. This one change would unlock powerful planning capabilities, simplify templates, and reduce manual overhead.

I'm looking to set a hard due date for milestones which prevents any slack beyond this point. Clickup doesn't seem to have this capability, the slack for one of my handover dates carries over until the due date of my last task, which is in a different list. I can see this has been requested by other users, but still no solution?

Primary task estimated completion date is allowed blank and automatically filled in by the furthest out subtask. The primary task completion date is dependent on subtasks. A common feature elsewhere. The impact of a subtask going long is immediately seen in all views but particularly in Gantt. With many team members working from disparate locations, the ability to impact the project by a simple task going long is not to be overestimated.

When a Parent Task has a due date set, subtasks should not be allowed to have due dates that extend beyond the parent’s due date. Ideally, there should be an option you can enable — one that enforces this restriction by default, but still allows flexibility when needed by manually overriding it.

Remapping recently broke: When you move a parent task later by 1 week, the subtasks remap. But when you move a parent task earlier by 1 week, the subtasks have stopped remapping. This is troubling because if we need to make projects due sooner, we have to manually remap all the subtasks.

We have an external team (not using ClickUp) that delivers assets (wiring diagrams, lineart etc.) that we use to create product artwork. I have these items as checklist items on specific artwork tasks the external assets are needed for. I don't uses sub-tasks for this because: I can't assign to someone not on my team and not using ClickUp. There isn't any "work" to be done by my team (anyone using ClickUp). It's just a blocking external dependency. So, It would be nice to allow Checklist items to have dependencies - e.g. artwork task "waiting on" checklist items A, B, C.

✅ This could be invaluable. This feature would make it possible for a parent task's (or subtask's) due date to change dynamically based on the date option selected. Without opening a task I would like to see the MOST RELEVANT date coming up for a key subtask. Options could be: ⏰ Show the date of the earliest/latest subtask (to see urgent deadlines or project lifetime) 🚩 Show the earliest/latest URGENT, HIGH, NORMAL, and/or LOW subtask 🧐 Show the earliest dependent subtask (blocking or waiting on) These dynamic values can be implemented into automations to see your most needed next steps. URGENT subtasks can tell you where you are at risk. LOW priority subtasks can be opportunities to celebrate a department or person for efficiency. Later subtasks can tell you how long a project is scheduled. Dependent subtasks can tell you which department to go to. Ultimately, this would help at a SINGLE GLANCE to know what is important from task to task. Not every task it necessarily time bound so this would allow to give a QUALITATIVE DATE over a QUANTITATIVE one.

So, it seems we have relationships for the sake of showing relationships. For example, waiting on, that seems like what we call predecessor for the given task. It's nice to see that there is something we are waiting on before this task can start, however, it also needs to show the impact to the overall schedule when the first task is delayed or even finishes earlier. Right now, we need to do a lot of manual adjustment to get a clearer picture of the critical path. For a smaller project, it's not bad, but when you have 1000s of tasks, this will become extremely challenging without having a proper relationships algorithm - that is impacting the dates - if one is delayed or finishes earlier - it should impact the related dates. Please include this for task management.

In MS Project or Primavera, the parent task depends on the duration of all the sub tasks. This is basic need for a Project Manager. We often create a parent task and add several subtasks with known start and end date. For example, Creating A certain Document - > Parent Task Prepare a draft - Subtask 1 Review the draft - Subtask 2 Update the draft - Subtask 3 Review and release - Subtask 4 Now, it's easier to put start and end date for all the subtasks, and the parent task start and end date will depend on the subtasks. In case one gets delayed or finishes early, we can adjust the subtasks and this should also update the dates for parent task. Please include this for the tasks management.

When copying tasks from one list to another, automatically copy the dependencies and apply those dependencies to the copied tasks to the new list. Currently, when copying tasks from one list to another, the dependencies are copied, but applied to the previous list.