Feature Requests

Hello! I'm a system administrator for a company with 120 employees, and I'm hoping to make a feature request. I would really appreciate it if we could have more control over custom permissions for each individual, and the ability to create permissions based on more options. Specifically, I'd like to set permissions for things like creating or copying a list, moving tasks to certain statuses, and restricting access to creating or updating labels. Basically, I want complete control over what each person can create or edit. For example, I'd like to restrict certain people from editing specific custom fields. Currently, the role system is limited, and some members have the same permissions as others, which isn't ideal. Many of my supervisors are members, but I don't want them all to have access to everything. While there are different roles we can create, the options for setting permissions are very limited. It would be great if we could have more flexibility in creating custom permissions for each individual.

See images in attachment. Public folders underneath private spaces inherit sharing permissions from the private space. I've shared the space with Teams ONLY, no individual users. Yet, the sharing modal currently works to actually inherit the individual users that are part of those teams to also be shown as individual people within the sharing modal as well. Feedback from the support team added below: Why individual users appear in the sharing modal This is currently how the sharing modal behaves for public locations. Even though those users are members of a Team that's been added, the modal renders them as individual entries rather than grouping them under their Team. It's a UX limitation, not a sign that someone manually shared with those users individually. When you switch a location (Folder) to private, the modal shows the cleaner Team-grouped view you're expecting. Your assumption about inheritance You're correct. Public locations under a private Space inherit the same access as the Space. So if your Space is private and shared with specific Teams, the public Folders, Lists, and tasks within it are accessible to those same Teams. No additional permission changes are needed for that setup. Getting to clean Team-only sharing For the cleanest view, the key is to set your locations to private and share them explicitly with your Teams. That way, the sharing modal will reflect exactly what you expect: Teams only, no individual user clutter. Just be aware that if anyone has been individually shared at any level (Folder, List, or task), that override will persist even after you restructure, so it's worth spot-checking a few locations after making changes. If you'd like to see improvements to how the sharing modal displays access for public locations, feel free to post your feedback at https://clickup.canny.io/feature-requests so our product team can track it.

The limitation The Progress (Auto) custom field only rolls up completion one level deep: from a top-level parent task down to its direct subtasks. Progress from nested subtasks (level 2 and deeper) is never included in the rollup. Impact Any task in the middle of a multi-tier hierarchy shows a flat 0%, even when its own direct subtasks are marked complete, because from the top parent's perspective those items are nested. This makes Progress (Auto) effectively useless for deep task trees. Confirmed not to be a config issue: the field's Subtasks completion type is enabled, and the "Complete" status is correctly categorized as Done. The 0% is purely due to the one-level rollup limitation. Request Allow Progress (Auto) to roll up nested subtask completion recursively across all hierarchy levels, or at minimum make the rollup depth configurable. Current workarounds Promote mid-tier tasks to top-level so their subtasks become direct children. Use a Progress (Manual) field on mid-tier tasks instead.

Through a recent support investigation, I was informed that the previous behavior, which allowed Private Custom Fields to be shared with specific Guest users, was not intended and has now been updated to function according to the intended permissions model. Under the current design, once a field is marked as Private, Guest and Limited Member access is completely blocked, and only Members can be added as exceptions. While the rationale behind the updated permissions model is understood, the previous behavior had been available for a long time and was actively used in established production workflows. A few examples: • Internal approval workflows • Employee, contractor, or supplier evaluation fields • Sensitive commercial or financial information • Client-specific operational notes However, the recent change created a significant gap for workflows that require confidential Custom Fields to be visible only to a small subset of designated users, including designated Guest users (external collaborators), while remaining hidden from anyone else. Following the permissions update, the only available alternatives are: • Making the field visible to all Guests • Promoting affected users to Members • Restructuring workflows around separate Lists and permissions models None of these options provide an equivalent level of control without introducing additional licensing costs, governance concerns, workflow fragmentation, or ongoing administrative overhead. More importantly, Workspace owners and administrators are now forced to choose between: • Exposing confidential operational data to a broader audience than intended • Removing the affected Custom Fields from their workflows • Redesigning existing workflows, SOPs, permissions structures, and operational processes around less efficient alternatives This change therefore impacts existing production environments that were already relying on this level of permissions granularity, while also removing a practical and proven access-control pattern that could otherwise be applied to future implementations. Requested enhancement: Reintroduce Guest exceptions for Private Custom Fields, enabling Workspace administrators to grant access to specific Guest users (or Teams) while keeping the field hidden from all other users. This would restore a practical and scalable permission model for confidential workflow data without requiring broader Workspace access, additional Member licenses, or workflow fragmentation.

I would like to suggest, to add the possibility to hide estimates and tracked time from other users in a more granular way. At the moment it is just possible to activate or deactivate this. Means, all users can see tracked time of other users and estimates of all tasks, if sharing is set on a higher level than tasks. As it is senseful to share at a project level in many cases, it is not always good to show all times and estimates of other tasks in this projects, especially, if there are mostly freelancers working in projects, like in our case. I would prefer to set estimates in the task individually for people with the possibility to hide this and also tracked time from others, except the e. g. the project admin ...

Can we have Workspace Owner and Admins visiblity to private spaces, folders, lists? It does not make sense the private space / list owners need to always need to add the Admins so they can run compliance auditing.

If a guest clicks “shared with me,” there are 3 default views (list, board, calendar) and I think this may confuse the guest. I would like the guest to access only the folder and list level views. I think that It is not necessary for the guest to have another level of views. Maybe when the guest clicks “Shared with me” the only thing that should happen should be opening the menu to actually show the shared items.

I had multiple ClickUp browser tabs open and was randomly signed out of all of them. I signed in again in one tab and was texted a verification code. I then had to do the verification code for the other tabs as well, and once signed in, was taken to my most recent page in ClickUp, NOT the last page I was on in that particular tab before I was prompted to sign in. So now I lost all the tasks I had open to work in. Feature requests: make the site redirect to the correct page + do not prompt me to log in & enter a code multiple times if I did it once in the same browser.

I’d like ClickUp to add a “View as Guest/User” mode, similar to Discord’s “View as” feature. As an admin setting up guest access, client workspaces, permissions, private folders, lists, docs, dashboards, and views, I need a safe way to verify exactly what a guest or specific user can see before inviting them. Right now, the workaround is creating fake test accounts with separate emails, which is inefficient and can be confusing. A built-in “View as Guest” or “View as User” preview would help admins audit permissions, prevent accidental exposure, and make client-facing setups much safer. Ideally, admins could select: View as a guest View as a specific user role View as a specific invited user Exit preview mode easily

I'd love to see a way to make a very easy way for each user/guest to mark their approval on a task. This would be particularly useful for reviewing designs with clients. While this can be done with custom statuses, that doesn't give the option for getting multiple people's approvals. I get the suggestion of assigning comments and asking for them to be resolved, but that's an obscure way to do this as opposed to a big, obvious, shiny "Approve" button that cant' be missed. This would be even better if there were multiple, or even customizable, options, such as: • Approved • Approved with Changes • Rejected (or Please Revised) • Finished Commenting Integrating this with the new Proofing feature would be great too, though that works on the attachment level, and what I'm suggesting would be on the task level. If this were implemented on each attachment to a task (and if there were multiple attachments) it would be great if the approval status were very obvious visually on the task view. • A