Feature Requests

Problem: Custom fields can become messy when you have different types of work (tasks) within the same lists. For example, having a bug, feature, and an epic task all in the same list would cause them all to have the same custom fields, even though I would want specific ones for each type. Other issues arise when fields that should only belong to the top-level task spread down to all its subtasks. Ask: Custom fields should have the option to be added to a custom task type itself. Whenever I create a new task of that type, it will come along with all its custom fields. Those fields will not spread to any task that is not of that type.

In Clickup 3.0 we can set "Default Task Type" in a list (Which is awesome). But it doesn't let you set default "subtask" types. e.g. - I want to make a "Person" task type for the default in my List, but I want each Sub-Task of those "People" to be an actual regular Task. (This will help me utilize CRM style functions, while letting those subtasks show up in my everything view as actionable tasks, without showing the CRM lead name, since those aren't actionable tasks...)

It would be great if in the Task View we could have the ability to customize (globally) the columns that we see next to each task. By default it is Assignees, Priority, and Due Date, with an option to manually add in columns, but that doesn't translate globally. I think a separate global setting for this would be a great addition as a lot of us are looking at start date and due date, not just due date.

I'd like support toggle lists as headings. On Notion, I can easily create a toggle list (there called an "expand") by typing the > character and transforming it into a heading toggle list by adding the desired level heading (up to heading 3 ###). We just transitioned from Notion and all of our meticulously crafted expands have been exploded for us, forcing us to reformat a lot of our tasks.

There is a compelling use case for having a parent Task inherit its Start-End dates based on the total duration for all subtasks. This should be an optional feature, to be enabled only for certain spaces/folders. Maybe it could be enabled at the task level independently - like a toggle to "Inherit Subtasks Duration" (or something more catchy?) For example - if we're building a single webpage, we'd make a top-level task: Build X Webpage. The actual duration of that task should be based on the total time required to complete all the subtasks, ie: UX Wireframe Design, UI Visual Design, FE Dev, BE Dev, QA, Dev Ops, Approvals, etc. Some of these subtasks can overlap, and some are dependencies on others, but ALL of them must be completed before the parent task is DONE. Additionally, it's hard to forecast an exact start and end date for each subtask. I want more flexibility to change the duration of subtasks and have the parent task inherit the overall duration of all tasks. In other words, the earliest subtask start date will be the parent task start date, and the latest subtask due date will be the parent task due date. While I can enable 'remap task/subtasks' so dependencies move the dates of the things they're blocking - they do NOT adjust the duration of the parent task.

I want to be able to easily access the top parent task from any sub-task no matter whether sub-tasks are nested within sub-tasks. This is needed for highly nested projects.

Allow users to design a completely customized task view. The default task view "form" should be saved per task type and allow for overriding at the list level. Completely customizable - as an extreme example - a user should be able to set up a task view to only see a single checkbox custom field with no task name, no description, no other intrinsic or custom fields or relationships shown. The only feature of the task view form that should be required is a border with a close button. Stop assuming that the Status, Task Name, Description, Priority, or Due Date will even be present in the task view at all and let the user decide the grouping and sorting of all fields. Don't assume that because you have to do more processing to handle relationships the user expects them to be in a separate presentation from custom fields. The user should be able to pull in any property of the linked task as the value of the field, or a calculated or rollup value. The table of subtasks should be available as an option to insert at any point in the form. It should have customizable rollup columns. Or the user should be able to have a simple count of subtasks or calculated/rollup displayed if that's all they want for the use case.