Feature Requests

Currently, when we create a task type, it becomes available across the entire workspace. This creates issues for standardization, as we want to enforce the use of specific task types within certain lists and even based on location. We’d like the ability to restrict task types to a list or location, so team members only see the relevant options. For example, in some cases, we only want three task types available within a given list. This functionality will help us: *Enforce consistency in how tasks are categorized. *Limit confusion by only presenting relevant task types. *Better leverage the beta functionality of fields tied to task types. IMPACT: Without this, team members can select incorrect task types, leading to data inconsistency and reduced effectiveness of field-based reporting and automation. REQUEST: *Ability to configure which task types are available per list, space, and/or entire workspace. Include the ability to manage ClickUp-created task types, such as Task, Milestone, Meeting Note, Key Result, Person, etc.) --By Location (Department/Team/Region): For example, the Sales – Europe list may only need three task types (“Lead,” “Demo Scheduled,” and “Contract Sent”), while Sales – US might require a different set. Restricting by location would keep task types relevant for each group. --Space: If an organization manages multiple workspaces (e.g., Operations vs. IT), admins could enforce different task type sets per workspace. This would prevent irrelevant task types from appearing in the wrong context (e.g., IT-specific types showing up in Sales). --Workspace: We may want to make certain task lists available across the workspace still. *Add to the space configuration/creation to set the task types available for each, in case there are no task types available at the workspace level.

It would be extremely valuable for ClickUp to allow due dates to be assigned to individual checklist items within tasks and subtasks. Today, checklist items are an excellent way to track smaller action items without creating additional subtasks. However, checklist items currently lack the ability to have their own due dates, making it difficult to manage time-sensitive deliverables that do not warrant a separate task or subtask. As a result, teams are often forced to create unnecessary subtasks solely to track deadlines, adding administrative overhead and increasing project complexity. Example Use Cases: Website Launch Task: Content Approved → Due June 15 QA Completed → Due June 18 Client Sign-Off Received → Due June 20 Go Live → Due June 22 Proposal Development Task: Discovery Notes Complete → Due July 5 Internal Review → Due July 7 Final Proposal Sent → Due July 10 Benefits: Provides greater accountability for checklist-level work Reduces the need to create unnecessary subtasks Keeps tasks cleaner and easier to manage Improves project planning and milestone tracking Allows teams to identify overdue checklist items before the parent task becomes overdue Supports more granular execution without increasing project complexity Ideal Functionality: Assign due dates to individual checklist items Display overdue checklist items visually within the task Surface checklist due dates in Calendar, Home, and Workload views Allow checklist items with due dates to trigger notifications and reminders Support filtering and reporting on overdue checklist items Enable automations based on checklist due dates or completion status Many projects contain important milestones and dependencies that are too small to justify a dedicated subtask but too important to be tracked without a deadline.

I have a few different spaces that contain records that are not tasks, so they are set up with a different task type. It might be a meeting minutes task type, a social post task type, an info task type, or a person task type, etc. They are set up as the default for the space. Often there are tasks that we need to add as subtasks to these records, for instance: Reaching out to a specific contact about something Updating a specific piece of information in one of our programmes Right now we have to remember to change those subtasks manually. It would be wonderful to be able to set a default task for subtasks that is different than the default for parent tasks.

I have an "invoice" task type that doesn't get its own list and generally is an outlier among other tasks on a project. This way I can filter my entire workspace for just invoices across all projects. I use the subtasks to log invoice numbers and payment status and have automations to set up assignee and dates, but the trigger right now is to type "invoice" in the subtask. Recently I forgot I had forgotten I'd created that trigger so have been manually assigning the task type to my subtasks. And since there are other people involved, we'd all have to remember to type "invoice" to trigger the automation. So I was thinking whether there could be an automation that was something like: "when subtask is created, assign task type to,' match parent task'".

I am a property manager and could use a few more features on this app. It has a lot going for it, and that's why I use it. But I think allowing for a database style list would be very helpful. Also being able to link tasks to the database items would be beneficial as well as a grid view for tasks. Embedding features to allow clickup to be one large dashboard that includes other sites would be phenomenal. I wish that I could see my emails in an email tab so I don't have to go to my Gmail to manage. I also wish that I could access my slack in the clickup app. Think tabs on the sidebar that have gmail and slack.

Currently, ClickUp allows users to create Task Types and assign different custom fields based on each Task Type, which is very helpful for structuring workflows. However, there is a limitation when using subtasks with different Task Types: When changing a subtask into another Task Type, the related custom fields of that Task Type do not appear in the parent task’s single task view. Even when trying to manually add custom fields into the view, there is no option to select custom fields based on the subtask’s Task Type. As a result, users need to open each subtask individually to access or update its Task Type custom fields, which reduces visibility and efficiency for operational workflows. Suggested improvement: Allow parent task views to display subtask custom fields dynamically based on each subtask’s Task Type. Allow users to select and show Task Type-specific custom fields in views, regardless of whether the fields belong to parent tasks or subtasks. This enhancement would significantly improve usability for teams managing complex workflows with multiple Task Types and structured subtasks.

It is currently not possible to sort the defined task types in the settings. Therefore, sorting in the list view is of no added value if the task types have not been created correctly from the start. Subsequent adjustments are impossible.

Currently, when using Custom Task Types, we lose the status view in a “pie chart” format present in standard tasks. The custom icon only changes color as the status progresses. The problem is that I'm color blind. Since custom icons rely solely on the color change to indicate status, I get seriously lost and have a hard time visually identifying what stage the task is in. The standard view in pie chart format (which “fills up” as progress) is a fundamental visual graphic aid for me, as it offers real accessibility based on shape/fill, and not just on color. I request that you add the option to keep the status pie chart for Custom Task Types, or provide a visual alternative for progress that doesn't rely solely on colors. This would make a huge difference in usability for users with color blindness. The submitted prints show how confusing the view is.

Right now, you can only set the default task type at the list level. New lists must be created with a template or manually changed to the appropriate task type, both of which are slow.

Multiple custom task types can be confusing if you use them a lot. Right now, custom task types are Workspace-wide by design, so there's no way to scope which types (and their fields) appear in a specific Space or Folder. My suggestion is to define task types and their related fields at the Space or Folder level