Feature Requests

I would like the ability to freeze additional columns so that key information remains visible as I scroll through columns to the right. This is critical for lists with a high number of fields (the list I'm currently using is about 30-40 fields), as otherwise I am forced to continually scroll left and right to see the key data I need on a task/project.

It would be very helpful for my team, most humans, since we are visual, to have the ability to display images in a field on the list/table view. competitive software have this feature, and the software I am trying to integrate also have this feature.

In the list view, tasks can be sorted by priority. The problem is that subtasks within the sorted tasks CANNOT be sorted. Currently, the only option is to display all subtasks in the same level. But in doing so, I lose structure. In other tools, z.B. Jira (screenshot), is that possible and the default setting. The effort required to adjust this should be very low and the benefits should be great. Please adjust that:)

ClickUp currently automatically groups tasks in the list view in “Group by: Due Date” into relative areas such as “Today,” “Tomorrow,” “This Week,” “Next Week,” and “Future.” This is well suited for short-term planning, but when planning over several weeks or an entire month, it quickly becomes confusing because many tasks end up in the “future” area. It would therefore be expressly desired not to change the existing standard behavior, but a configurable setting within the list view. For example, when grouping by due date, an additional granularity setting could be offered: Standard/ current grouping daily weekly If set to “daily,” each calendar day would be represented as a separate group, for example: 01.10.2026 Task A Task B 02.10.2026 Task C 03.10.2026 Task D Use case: I sometimes plan my tasks several weeks or a whole month in advance, especially before vacations or periods of heavy workload. To do this, I need to be able to see how many tasks are on each individual day and be able to specifically postpone tasks to other days. The current “Future” collection group makes precisely this type of capacity and monthly planning much more difficult. Key requirements: Use the normal due date no additional custom fields required Configuration directly in the view settings Existing behavior is retained as standard optional daily grouping over longer periods Drag & drop between day groups to directly change the due date Number of tasks per day group visible optional: sum of time estimates per day group I am aware that daily grouping over long periods of time can technically load more data for a lot of tasks and may be slower. In my opinion, however, this should be deliberately left to the user. For detailed planning, a slightly longer loading time would be significantly less problematic than a lack of overview. The most important thing is therefore: The granularity of the grouping by due date should be configurable.

It would be great to include relationship data and rollup fields in an export of a list view.

The Task Visibility option in the Calendar View is helpful; having this option in the Table View would be helpful as well. Or having a similar type of conditional formatting where when a certain aspect of a task has changed, the whole line highlights a specific color or changes formatting.

Table view is great, but subtasks are detached from the main parent tasks. Is there any way sub-tasks can be displayed under the parent tasks, maybe a tap in so they appear less in visual hierarchy?

Please add the ability to search through relationship fields. At the moment, even if "search in custom fields" is active, it won't search in relationship fields.

Title: Expose Label Custom Field color (hex) values in the API response Category: API / Custom Fields Description: Currently, when retrieving Labels-type Custom Field definitions via the API (e.g., Get Accessible Custom Fields or Get List/Folder/Space Custom Fields), the response includes each label option's id and value (name), but does not include the color associated with each label. In the ClickUp UI, label colors are a core part of how users visually distinguish categories. However, this color information is completely absent from the API, making it impossible for integrations and automations to faithfully reproduce the visual representation that users rely on. Real-world problem: I manage a large project (130+ tasks) with multiple Labels fields used for team/role assignment (主担当, 副担当, etc.), each containing 19 label options with carefully chosen colors for quick visual identification. When I try to export the task list to PDF (via ClickUp Brain or external tools), the label badges cannot be rendered in the correct colors because the API simply doesn't provide them. The only workaround today is to manually extract each label's hex color from the UI (e.g., by inspecting elements or taking screenshots) and provide them to the export tool by hand, every single time the colors change. This defeats the purpose of having an API. What the API currently returns: { "id": "ca5e1bc7-...", "name": "主担当", "type": "labels", "options": [ { "id": "8aa55602-...", "label": "企画G" }, { "id": "3df84111-...", "label": "ライフ･物材U" } ] } What it should return: { "id": "ca5e1bc7-...", "name": "主担当", "type": "labels", "options": [ { "id": "8aa55602-...", "label": "企画G", "color": "#0091ff" }, { "id": "3df84111-...", "label": "ライフ･物材U", "color": "#30a46c" } ] } Use cases enabled by this change: Accurate PDF/report generation with color-coded label badges matching the ClickUp UI External dashboards and BI tools that reflect the same visual language as ClickUp ClickUp Brain integrations that can render faithful visual exports without manual color input Automation workflows that reference label colors for conditional logic or notifications Additional note: This also applies to ClickUp Brain's internal API access. Brain currently cannot read label colors either, which limits its ability to generate accurate visual exports, a feature that would otherwise be a great showcase of Brain's capabilities. This seems like a small, non-breaking addition to the existing API response schema that would unlock significant value.

Another post says this was completed back in 2019, but when I try to print with darkmode on, the whole page prints black. Obv unreasonable. Please add print functions!