Feature Requests

Currently in ClickUp, a Workspace Owner can be completely locked out of content within their own workspace. When a member creates a private Space, Folder, List, View, or AI Agent and restricts sharing to only themselves, the Owner has no ability to see, manage, or reassign that content, even after the person leaves the organization. The problem (real scenario): A team member creates a private Space/List for their work and sets permissions to "only me." That person leaves the organization. The Workspace Owner now has zero access to all tasks, docs, and data inside that location. There is no way to reassign permissions, recover the content, or give the replacement hire visibility. All organizational work product is effectively lost, trapped in an orphaned private location. The same issue applies to: Views: Private views with valuable filters/configurations that no one else can access or replicate. AI Agents: A departing user may have built sophisticated Agents with custom instructions, knowledge, and workflows. If set to personal access only, the Owner cannot see, manage, transfer, or even know they exist. The Agent (and all the institutional knowledge encoded in it) leaves with the person. Why this is fundamentally wrong: The Workspace Owner pays for the platform. They represent the business entity. Work created within a paid organizational workspace is organizational IP, not personal property. ClickUp already provides Personal Lists and DMs/Chat as truly private spaces. These are appropriate for personal content. Everything else (Spaces, Folders, Lists, Views, Agents) is organizational infrastructure and should never be hidden from the business owner. Even confidential content (HR, finance) should be visible to the Owner because the Owner IS the business. Confidentiality from admins ≠ confidentiality from the owner. Proposed solution: Workspace Owner override: The Workspace Owner should have unconditional, non-revocable access to view and manage ALL content in the workspace: every Space, Folder, List, View, Dashboard, and AI Agent. No individual user should be able to create content that the Owner cannot see or manage. Owner can always reassign sharing & permissions on any item, regardless of who created it or how it was shared. Scope of override (Owner can always): -See all private Spaces, Folders, Lists, and their contents. -See and manage all Views (including private views created by others). -See, manage, transfer, and reassign ownership of all AI Agents. -Modify sharing & permissions on any item in the workspace. What remains truly private (Owner does NOT access): Personal Lists (designed for personal task management). Direct Messages and private Chat conversations. Personal notifications and preferences. Admin vs. Owner distinction: Admins may still have restricted visibility (some content can be confidential from admins, e.g., HR data). Owner has absolute override. The Owner is the ultimate authority and the legal entity responsible for all workspace content. Offboarding workflow: When a user is deactivated/removed, all their privately-owned content (Spaces, Lists, Views, Agents) should automatically surface to the Owner with a prompt to reassign or archive. No content should ever become "orphaned" and inaccessible. Why this matters: Prevents permanent data loss when employees leave. Prevents organizational AI knowledge (Agents) from walking out the door. Eliminates a fundamental governance gap where employees can hide work from the business that pays for the tool. Aligns with enterprise security expectations: the paying entity always has ultimate authority over its data. Solves compliance requirements (legal holds, audits, records requests) that mandate organizational access to all work product.

ClickUp currently ties all sharing, permissions, and asset ownership to individual users. There is no concept of an organizational role/position that carries permissions and owned assets independently of the person filling it. The problem: In any organization with staff turnover or role changes, two critical issues arise: Permission chaos on every personnel change: New hire joins → Admin manually shares dozens of Spaces, Folders, Lists, Views, Dashboards. Someone leaves → Admin manually revokes and reassigns everything. No single source of truth for "what does this position need access to?" Knowledge & asset loss when people leave (especially AI Agents): Users build Super Agents with custom instructions, knowledge bases, and workflows tailored to their role (e.g., a Copywriter Agent, a Campaign Analyst Agent). These Agents are tied to the individual creator with personal sharing settings. When that person leaves the organization, their Agents leave with them. The admin has no authority over personally-owned Agents. The replacement hire starts from zero: rebuilding Agents, re-uploading knowledge, re-configuring workflows. All institutional AI knowledge is lost. This is especially painful because building a good Agent represents weeks of iteration, prompt refinement, and domain knowledge encoding. It's organizational IP, not personal property. Why Teams don't solve this: Teams group people, not positions. They don't transfer ownership of assets (like Agents) when someone leaves. And admins still can't reclaim personally-owned Agents from departed users. Proposed solution: Introduce Organizational Roles/Positions as a first-class entity for both permissions AND asset ownership: Permissions: Define roles ("Brand Manager", "Copywriter", "Campaign Lead") that exist independently of who fills them. Assign sharing & permissions to Roles for Spaces, Folders, Lists, Views, Dashboards, Custom Fields. When the person changes, simply reassign the Role → all permissions transfer instantly. A person can hold multiple Roles, inheriting combined permissions. Agent & Asset Ownership: Allow Agents (and other key assets) to be owned by a Role, not just an individual. Agents owned by a Role are accessible to whoever currently holds that Role. When a person leaves, Role-owned Agents remain in the organization. The new hire inherits them immediately. Admin always has visibility and override authority over Role-owned Agents (unlike personal Agents today). Option to enforce a policy: "All Agents created by this Role must be Role-owned" to prevent personal hoarding of organizational AI. Audit & governance: See who held which Role and when. Track Agent ownership history and modifications. Integration with HR/SCIM so role changes auto-propagate. Example: A Copywriter builds a "Brand Voice Agent" with detailed tone guidelines, past campaign knowledge, and content templates. They set it as owned by the "Copywriter" role. Six months later, the Copywriter leaves. New hire arrives, gets assigned the "Copywriter" role, and instantly has: Access to all relevant Spaces, Lists, and Views The fully-trained Brand Voice Agent ready to use on day one Zero admin tickets, zero lost knowledge Why this matters: Eliminates repetitive admin work on personnel changes. Prevents loss of organizational AI knowledge when people leave. Treats Agents as organizational assets, not personal toys. Reduces onboarding time for new hires from weeks to minutes. Aligns with how enterprises think about access and IP: by role, not by name. Scales for organizations with high turnover without constant admin intervention.

Description We’d like the ability to restrict users who already have access to a Space, Folder, or List from granting access to other users. Today, sharing behavior depends on the location type and the user’s permission level, but there is not a dedicated setting that universally prevents onward sharing. This makes it difficult for admins to fully control access, especially in environments where content should only be shared by workspace admins, owners, or designated managers. Requested behavior Add a setting that prevents users from sharing a Space, Folder, or List with additional users unless they are explicitly allowed to do so. Ideally this could be configurable at the Workspace or location level. Bonus if this can be controlled separately for Spaces, Folders, and Lists. Use case Our team keeps Spaces private and manually invites the correct users, but once someone has access, we want the option to prevent them from resharing that access to others. Why this matters This would help with: stronger access control cleaner permission management reduced risk of accidental over-sharing better governance for teams with sensitive or department-specific work Current workaround The closest workaround is keeping locations private and assigning permissions carefully, but that does not fully solve the issue because it does not create a true “no resharing” rule.

We need a permission level that restricts team members to only see tasks assigned to them within a shared List or Folder. Use case: Our team manages tasks in a single List, but team members should not see each other's tasks. Currently, Me Mode provides a visual filter, but it's not a real restriction since anyone can disable it and see everything. Current workarounds (and why they fall short): Me Mode: Only a visual filter, not a security boundary. Users can turn it off. Guests: Would work, but Guests lose access to Spaces, can't create views, and may add cost depending on the plan. Not practical for internal team members. Private tasks + automation: Requires sharing each task individually. Hard to maintain at scale. Proposed solution: A new permission option at the List or Folder level, something like "Can only view assigned tasks." This would allow the member to remain a full Workspace member while restricting their visibility within that specific location to only tasks where they are an assignee. This would be incredibly useful for teams handling sensitive or individual work (HR, legal, sales pipelines, support tickets) where privacy between team members is important.

Please enable a feature to add same Organizational Domain Users as Guests.

In many systems, admins have the ability to put a user on hold so they can't access their account before you deactivate or remove them. This allows you to ensure an employee who is being terminated involuntarily does not have access to important data (and can delete data) ASAP. ClickUp only allows admins to deactivate, and then it labels the user as deactivated. I'd love to be able to lock as an intermediate step prior to when we notify staff so that I can preserve our security, but wait to have to take next steps.

We currently have the “Save automatically for me” setting, so if it is active, in scenarios where I have written ONLY the title or ONLY the description and end up clicking outside the draft space, ClickUp will open a window asking if I want to save the draft, preventing the draft from being permanently deleted. If the “Save automatically for me” setting is not active and the same situation described above occurs, the window asking if I want to save the draft will appear ONLY if I have written a title, but it will not appear if I have written only a description, which will cause me to completely lose and without the possibility of recovering the information I entered in the draft description.

We desperately need a Discoverable Permission to bring hidden items (not shared with everyone) out of the shadows and allow collaboration. We have Spaces set up and restricted by Team, which makes sense to reduce ClickUp noise when you have over 100 users in different teams. This reduces accidental noise, but especially helps when searching for tasks. The problem is this impacts collaboration as how does Team A share a task with Team B. The optimum way to do this that works really well is Add to List, so we add to both Team A and Team B list. The problem: Only a user who has access to both Team A and Team B List can add a task to both. The solution: What is needed is a Permission that allows users to see the Space, Folders & Lists for the purpose of sharing a task using "Add to List". This would use the "Add to List" to add a Task to a secondary List for another team, which makes it available to both Team A and Team B. This would simply be a new permission of "Discoverable", which would still give Organisations the ability to hide Spaces or Lists if they determine these are sensitive. Use cases: Main use case "Add to List" - User can see Discoverable Lists when they use "Add to List". Optional is that discoverable lists are hidden by default and a toggle option shows them. Heirarchy Explorer: Users can toggle on to find a Space, Folder or List they currently don't have permission to. This is similar to Chat where they are following Chats, but others are still discoverable to Join. With Discoverable permission some minor detail may be visible to allow decerning the use of this List .... the List name, description, owner and members could be visible. A new feature of Ask to Join, could be added in future that would allow a user to request access through the app. In stage 1 just having user be able to find a List and see who owner is allows them to request permission. Repair the "SILO ISSUE"... every other day we are impacted by the SILO ISSUE where tasks are hidden that should not be due to being made private to a user. This is the reason I advise everyone not to get involved with ClickUp as it is good, but also a primary cause of Complaints in our business. If ClickUp really cared about its customers it would fix this issue and it is really really easy with this solution. If a Clickup of tasks, lists etc is made Private then the Space Owner and Workspace Owner would always have a locked right of Discoverable. Use case 3 I have also included Tasks, although this permission main needs are for Lists. Tasks currently continue to be hidden, usually accidentally due to need for some privacy eg: a complaint about a specific person. However, current design means the Workspace Owner and Space Owner also lose visability. I had a Folder I could delete, but actually had Lists and Tasks I was not privy to. As of today ClickUp still tells me the Folder is empty 🤯 There should be no process that blocks Owners from content in their areas. Owners should be default minimum of Discoverable on any item, including Tasks in their areas. Personal Spaces are another minefield outside of the Spaces heirarchy, and for these I suggest model that the Workspace Owner and an assigned Manager (and manager's manager up the heirarchy) should always having minimum of Discoverable rights to these Tasks. After discussions with over 15 ClickUp staff noone has yet explained the strategic reason ClickUp still persists in restricting companies from their data. It is not a schematic issue that cannot be resolved, it is someone who has chosen this. They claim to escalate and then goes into a void of no response. I think it may be some fallacy of being the people's champion and protecting the Privacy for individual users. What ever the reason in the real world it just leads to COMPLAINT after COMPLAINT after COMPLAINT... sarcastic "thank you ClickUp". If PRIVACY is the made up reason for this SILO ISSUE then simply seeing that a task exists is needed, which is already done in Personal Priorities list. See image... "private task". I can see my Service Manager for team has a private task as fifth on his list. I would suggest that even if Task Name is hidden that some key data points are shared that give context. Primarily the Task ID, Created Date, Due Date, Status (already shared) and Assignee. ... this then allows a manager to query "why do you have a task that is 5 weeks overdue". Seeing the ID gives no further information than giving some identifier for a task that may be stagnant.

Title: Feature Request: Time-Based Session Expiry Scheduling Description: Currently, ClickUp's session management expires authentication based on a rolling duration (e.g., 7 days from login). This means re-authentication can happen mid-workday, disrupting productivity. Request: Add the ability to configure session expiration to occur at a specific time of day (e.g., 6:00 AM local time) rather than purely duration-based. This would ensure users re-authenticate before their workday begins rather than being interrupted during active work. Use case: Our workspace enforces 7-day session duration for security compliance. Users frequently get logged out mid-task, causing friction. A scheduled expiry window (e.g., "expire sessions between 5-7 AM local time") would maintain security posture without impacting productivity.

Good morning, I added cumulative fields to a view but when I make a public link to share the view with my external partners, the accumulation values are not visible. This impacts my collaboration with my partners who must be able to visualize this essential information. Please fix this feature. Thank you so much and have a great day,