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.
