James Hogg
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:
  1. 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.
  2. 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.
  3. 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.

Photo Viewer

View photos in a modal