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.

When a Task is linked, or a Custom Relationship is added, the Task name should be visible.

Loving 3.0 task views and inbox/notifications. My one ongoing gripe is the continued lack of exposing the folder level breadcrumbs in various task and notification views. Like many who use this platform we use templates with generic lists and tasks and the only way to identify what project you're looking at is to drill up through the hierarchy with a bunch of clicks until you get to the folder level. Older classic notification screen allowed you to expose the breadcrumbs, but not so on 3.0. I need this option essentially everywhere and particularly on the new Inbox and also Mobile.

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.

Problem: Often within a single list, we have different types of tasks: some represent projects, designs, and smaller action items. Each one should go through their own set of statuses, but this is currently not possible. We are forced to either use dropdown custom fields as a workaround or create large status sets to try and encompass everything, leading to confusion among people. Ask: Give the ability for statuses to be set by type. This will allow each task type to have its own status workflow.

Problem: We manage different types of work within ClickUp, and how sections are organized in ClickUp Tasks do not always work across each type. In some tasks, for example I want subtasks and fields front and center, while in others, I need to bring relationships front and center. Ask: Give the ability to have a different task layout for each task type. This would allow each type to have a layout that is better organized for that type of work.

It can be confusing when you toggle on in list view and the subtasks show up, but there is no indication of what the parent task is.

At the moment, task types are Workspace-wide. However, different teams have different needs as far as task types, which is why Space-level or private options would be optimal. For example, an HR team wouldn't rely on the same task types as an IT team. Each department may have sensitive information in their workflows (represented by a task type) that they don't want other teams to have visibility on.

When I create any task with subtasks, the dates of the subtasks are often tied (in real life) to the dates of the parent task. It would be great if we could explicitly set the due date of the subtask to be relative to the due date of the parent task. So if I set the due date of the subtask to "1 day before the parent due date", and then set the parent's due date to Dec 12, the subtask would appear to be due on Dec 11. If I later change the due date of the parent task, the subtask will automatically move with it. Now, when the parent task is also a recurring task, the same principle should apply to each recurrence. Right now, the more subtasks a recurring task has, the more tinkering and time-wasting needs to be done just to get them working right at each recurrence. It's very annoying. So if I create a parent task that's due on the 1st of each month, and add a subtask that's due 1 day before the parent task is due, and choose "Create new task" every time the parent task recurs, I'd expect the following behavior to take place when the first parent task is done or closed: * A new parent task is created that's due at the next interval * A new subtask is added to the new parent task, and its due date is 1 day before the new parent task's due date * I wouldn't have to do any tinkering to get the new subtask to properly align with its new parent task I imagine it's probably more complicated when a new task is not created because you'd have to deal with situations in which some subtasks haven't been completed yet. It seems to me that you can add an option to the recurrence rules to either recur subtasks with the parent regardless of their individual status, or to only recur subtasks that are complete. In any case, adding relative due dates to subtasks will make recurring tasks with subtasks actually usable, more tinker-proof, and more intuitive.