Feature Requests

There are no security permissions that can be set to control who can create a task type. We want to limit this to specific roles. We are on the custom field by task type beta and having other users able to create multiple task types can get confusing.

Right now, the ability to see which Docs, Lists, and views in your workspace have been publicly shared — and to manage or restrict that sharing — is locked to the Enterprise plan. That's a problem for every team below Enterprise, because: -You can't audit your own exposure. Anyone on your workspace can generate a public link to a Doc, and admins on lower tiers have no consolidated way to see what's currently shared, when it was shared, or by whom. -ClickUp has bugs. We all file them. Sharing behavior is exactly the kind of surface where an unexpected bug shouldn't be undetectable for the customer. -Sensitive client and internal docs live in ClickUp. SOPs, client deliverables, contracts, internal strategy. Visibility into what's shared externally is a baseline trust requirement, not an advanced governance feature. -Most paid SaaS tools include this at every tier. Notion, Google Workspace, Asana, Confluence — sharing visibility and admin controls over public links are part of the base product. What I'm asking for: -A workspace-level view of all publicly shared items (Docs, Lists, views, etc.) with who shared them and when — available on Unlimited, Business, and Business Plus. -Admin ability to restrict or disable public sharing at the workspace, Space, or role level — available on Business and above. -Keep advanced governance (audit log exports, SCIM, SSO-tied policies, compliance tooling) on Enterprise. That's a fair line. Sharing visibility isn't a premium feature. It's how customers verify the product is behaving the way they think it is. Please reconsider the packaging.

We migrated from Adobe Workfront about a year ago and one of the features that it has is the ability to delegate user assignments or approvals if someone is out of town or out sick, etc. It made things really nice so that workflows continued to flow without have to reassign task. It would be wonderful if that same kind of feature was included within ClickUp. https://experienceleague.adobe.com/en/docs/workfront/using/manage-work/delegate-work/delegate-work-overview

Feedback: Misleading UI in Sharing & Permissions Dialog Caused Unintended Billing for 6 Paid Seats (~$1,500 USD) Summary: When inviting users via the "Sharing & Permissions" dialog on a List, the "Default permission: View only" setting does not invite users as "Limited Member View Only" (a free role). Instead, it invites them as "Limited Members" (a paid role) with View Only permissions scoped to that specific List. There is no warning that this action will add paid seats and trigger billing. This distinction is not made clear anywhere in the dialog, and even ClickUp's own AI assistant (Brain) was unable to correctly distinguish between the two, giving the user incorrect guidance twice. Timeline of Events: User's goal: Invite 6 colleagues to view project data in a ClickUp Space without incurring additional charges, using the "Limited Member View Only" (free) role. Brain's initial guidance (incorrect): ClickUp Brain advised the user to right-click a List, open the "Sharing & Permissions" dialog, and invite users with "View Only" permission. Brain stated this would result in free, view-only access. User followed the guidance: The user opened the "Share this List" dialog on "All Task List 01," set "Default permission" to "View only," and invited 6 people. Result: All 6 users were registered as "Limited Members" (paid role), not "Limited Members View Only" (free role). The user's credit card was charged approximately $1,500 USD (6 paid seats) with no confirmation prompt or billing warning before the charge. Brain's second response (also partially incorrect): When the user reported the issue, Brain apologized and suggested changing each user's permission to "View Only" in the People settings, claiming this would convert them back to the free "Limited Member View Only" role. The user correctly identified that this advice was also likely wrong: the "View Only" permission in the sharing dialog controls location-level access, not the workspace-level user role. User's own analysis (correct): The user pointed out that "Permission: View Only" in the Sharing & Permissions dialog sets the access level for that specific location only. It does not determine or change the user's workspace role. To be invited as "Limited Member View Only" (free), the role must be explicitly selected elsewhere, likely in the People/Manage People settings, not through the sharing dialog. Core Issues: No distinction in the UI: The "Share this List" dialog offers a "View only" permission option but does not indicate that this is a location-scoped permission, not a role assignment. There is no mention of "Limited Member" vs. "Limited Member View Only" anywhere in this dialog. No billing warning: Inviting users through this dialog silently adds paid "Limited Member" seats. There is no confirmation step, no cost estimate, and no notice that the user's payment method will be charged. Even ClickUp Brain was confused: ClickUp's own AI assistant could not correctly distinguish between the "View Only" permission level (location-scoped) and the "Limited Member View Only" user role (workspace-scoped, free). Brain gave incorrect guidance twice, demonstrating that the naming and UX are genuinely confusing, not just to new users, but to the AI trained on ClickUp's own documentation. Recommendations: Add a billing confirmation step when inviting users through Sharing & Permissions that would result in new paid seats. Display the cost before the invitation is sent. Clarify role vs. permission in the sharing dialog. Either allow explicit role selection (Limited Member vs. Limited Member View Only) in the dialog, or display a clear label showing which role the invited user will receive. Rename or differentiate more clearly between "View Only" as a permission level and "Limited Member View Only" as a user role. The current naming is a trap. Update Brain's training data to accurately reflect the distinction between location-level permissions and workspace-level user roles, so the AI does not repeat this mistake. User context: New ClickUp customer (approximately 1 week), university research infrastructure manager (Osaka University, EPOCH project), migrating from Zoho. This experience has significantly undermined trust in both the platform's billing transparency and the AI assistant's reliability.

Allow owners to specify the IP addresses that can access ClickUp. [Submitted via Support Ticket]

We use Clickup for all company subjects, including for HR monitoring with very confidential information, currently all it takes is one click by mistake and the entire HR space is accessible to all employees, by making the lists as private this reduces the risk of error, but by managing the rights of the lists, it is once again sufficient to click by mistake and the list is accessible to the wrong people. Would it be possible to be able to request authentication every time you want to be able to add new users in the clickup settings? and also to be able to limit the members who have the ability to change rights and add users to a list

It would be nice to be able to select to have sydonames for users within the Workspace, or have the ability to remain anonymous while still being able to interact with other members within the Workspace.

In the “spaces shared with me” part, there are no spaces that are already shared with me. There seems to be some bug with our space.

Hello CU Team, I have no idea if this is possible, but it would be AMAZING if you could create an integration with Microsoft products where when you copy a link to a CU task, when pasted it will automatically adjust the to the name of the task. I am thinking this would be similar to the feature within Microsoft products where when you copy and paste a link to a document, it automatically adjusts to a hyperlink with the document title as the text.

It would be useful to have a permission at the Space, Folder, or List level that allows users to see only tasks relevant to them, without needing to configure privacy and sharing individually on every task. A common example is an IT Support list. The person affected by a support ticket needs to be able to view and interact with their own ticket, but they should not necessarily be able to see everyone else's support tickets. Currently, achieving this through task-level privacy and sharing is cumbersome and difficult to manage at scale. A hierarchy-level permission that automatically applies this visibility rule would be much simpler administratively and may also reduce the complexity of permission queries across large Lists. Possible implementation We currently use a Users Custom Field to identify the users affected by each task. This keeps the affected users visible in the List view while keeping them separate from the Assignee, who is the person actually responsible for completing the work. We also explored using Followers, which could be a natural way of defining who is permitted to see a task. However, Followers currently cannot be displayed as a column in List view, which makes them less practical for this purpose. A possible permission model could therefore be: Users with this permission can see the List, but only see tasks where they are a Follower, or included in a specified Users Custom Field. Users with this level cannot be added as Assignee. ClickUp could allow a particular Users Custom Field to be nominated as the visibility field for a List. The Restricted Visibility permission would only become available when that feature is enabled for a List and a qualifying Users Custom Field has been selected. This would provide a scalable way of supporting use cases such as IT support, HR requests, service requests, client-facing tasks, case management, and other Lists where users should only have access to tasks that relate directly to them. Keywords restricted task access, only see involved tasks, only see watched tasks, users only see followed tasks, Inherited Permissions, Inherited Sharing Similar Tasks https://feedback.clickup.com/feature-requests/p/give-permission-by-assigning-task https://feedback.clickup.com/feature-requests/p/permission-to-view-only-tasks-assigned-to-user-or-created-by-user "Assigned Permission" for task access The similar tasks talk of a related permission level which would be Assigned Permission. Users in this group would not automatically be able to see tasks within that location. Instead, they would only gain access to a task when they are explicitly added as an Assignee. Importantly, a user with Assigned Permission would not be able to give themselves access to additional tasks, and should not be able to add or remove assignee. They could only be added as an Assignee by a user with normal/full edit permissions. For example: A group of restricted users is added to a List with Assignee Permission. Those users initially see no tasks. A full edit user assigns a particular task to one of those users. That task then becomes visible and accessible to the delegated user. Other tasks within the List remain completely hidden from them, but the List stays nicely in Spaces Hierarchy for them. This would allow organisations to maintain a single operational List while securely delegating individual tasks to staff, contractors, external providers, or other restricted users without having to configure privacy settings separately on each task or having tasks just shoved into an unstructured Shared with Me folder. The critical benefit is the assignment is controlled and the flow of sharing becomes natural instead of current flow, which is forced.