Feature Requests

Please search first before posting to help others find and vote for your idea!
Granular Guest access to Private Custom Fields
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.
0
·
Sharing, Permissions,…
Private Custom Field exceptions cannot include Guests (need field visibility per guest group)
I’m trying to configure a Number Custom Field that should be visible to some Guests (clients) but hidden from other Guests (freelancers). Both groups must remain Guests and must have access to the same tasks. What I expected: Use Custom Field permissions and Exceptions to allow visibility for the “clients” group, while preventing visibility for the “freelancers” group. What happens: If the Custom Field is public and “Visible to Guests and Limited Members” is enabled, then all Guests can see it. There is no way to exclude one Guest group only. If I set the Custom Field to Private, the “Visible to Guests and Limited Members” toggle gets disabled (expected), but then: Guests that were previously added in the permissions/exceptions disappear after making the field Private, or When the field is Private, I cannot add Guest users to Exceptions at all (they do not appear in the “Add exception” user picker). Only members/teams seem selectable. Goal: Keep tasks shared with both client Guests and freelancer Guests. Make a specific Custom Field visible only to client Guests, and not visible to freelancer Guests. Question: Is it expected that Guests cannot be added as Exceptions for Private Custom Fields? If yes, is there any supported way to achieve per-guest-group Custom Field visibility when everyone must remain a Guest and work on the same tasks?
0
·
Sharing, Permissions,…
Make sharing visibility & public-link controls available below Enterprise
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.
0
·
Sharing, Permissions,…
Load More