Advanced Permissions/Permissions per user
building now
J
Justin Hayes
Hello! I'm a system administrator for a company with 120 employees, and I'm hoping to make a feature request. I would really appreciate it if we could have more control over custom permissions for each individual, and the ability to create permissions based on more options. Specifically, I'd like to set permissions for things like creating or copying a list, moving tasks to certain statuses, and restricting access to creating or updating labels. Basically, I want complete control over what each person can create or edit. For example, I'd like to restrict certain people from editing specific custom fields.
Currently, the role system is limited, and some members have the same permissions as others, which isn't ideal. Many of my supervisors are members, but I don't want them all to have access to everything. While there are different roles we can create, the options for setting permissions are very limited. It would be great if we could have more flexibility in creating custom permissions for each individual.
Log In
Armine Seropyan
Hey everyone!
We are working on the change that would help to define exactly what users can and can't do on different hierarchy locations, going beyond the standard pre-defined Full, Edit, Comment, and View Only levels.
You'll be able to create permission sets that combine specific actions like creating tasks, managing statuses, editing custom fields, tracking time, and assign it to teams or users.
Open to chat more about this change — appreciate everyone's feedback here! 🙏
Philip Lucas
Excellent! Could we please also make it so that Admin and Owner (or at least one of them) can access ALL Spaces/Folders/Lists in a workspace even if they are marked private?
Brenno Vicario Nicolau
At the moment, enabling Protect View prevents users from saving changes to a view; however, it still allows temporary modifications during their session (such as adjusting filters, sorting, grouping, or columns). While these changes are not persisted, they can still lead to inconsistencies in how information is displayed and interpreted across the team.
For certain operational and standardized workflows, it is essential that specific views remain completely immutable—not only in terms of saving changes, but also in preventing any form of temporary modification.
Introduce an option within Protect View that enforces full immutability, ensuring that:
1) Users cannot modify filters, sorting, grouping, or visible fields
2) The view remains exactly as configured for all users at all times
3) Any attempt to change the view is restricted or disabled
This would be especially valuable for teams that rely on consistent, standardized views for reporting, auditing, or operational control.
Michał Mrzygłocki
Delete custom field should be only for admins and owners
Steve Lee
It would be great if we can manage the permission to change the task status by user level, especially for guest users. For an instance, I would like to prevent the guest users changing the task status.
Armine Seropyan
Hey everyone!
We are working on the change that would help to define exactly what users can and can't do on different hierarchy locations, going beyond the standard pre-defined Full, Edit, Comment, and View Only levels.
You'll be able to create permission sets that combine specific actions like creating tasks, managing statuses, editing custom fields, tracking time, and assign it to teams or users.
Open to chat more about this change — appreciate everyone's feedback here! 🙏
Yisroel Falkowitz
Armine Seropyan Can't wait, Thanks for the update.
S
Scott Johnson
Armine Seropyan - we would need to be able to control who has delete permissions for areas including custom fields and tasks,
A person who does not have custom field permissions should be able to add to existing custom fields in the list such as labels, dropdowns.
the protect view setting can be edited by anyone with edit access to the list where as the person locking the list should control this with admin override -
we need to be able to control views so you only see the view shared, in an example the view shared is filtered to restrict certain data and this is protected view where only the controller / admin can change. The person only sees the view shared with them, at the moment you have to give access to the default view which makes the implementation not possible.
I am sure there are several other standard admin permission controls which are hopefully also on the list.
Mark Verschuuren
Armine Seropyan manage who is allowed to create a task or subtask or even see or not see the subtasks
Armine Seropyan
Mark Verschuuren: Separating subtask permissions from task permissions is not in scope for the project I mentioned above. It has come up before and it's something we want to address, but we are evaluating separately.
Addy Koo Chong Tee
Armine Seropyan we would need different permission for users like requestor only able to submit the forms, can view the task details but not able to edit the task details. Currently the requestor is able to manual change the status which is not practical if we do set the automations.
When we create the Approval checkbox, only certain users are able to edit the checkbox, but it is quite challenging to manage the approval checkbox field. I have a global permission for approval, that will help to manage easily.
Vikram C
Armine Seropyan Advanced Permissions – Key Requirements
Field-Level Restrictions
Restrict editing of fields like Start Date, Due Date, Priority, Time Estimates based on roles.
Example: Only Project Managers can edit Due Dates, only Team Leads can change Priority.
Lock critical fields after certain statuses (e.g., Due Date locked after “Ready for QA”).
Status Transition Control
Define who can move tasks between statuses.
Example:
Developers: In Dev → Ready for QA
QA: Ready for QA → Done
Managers: Full access
Restrict reverse transitions (e.g., Done → In Progress).
Mandatory Fields Before Status Change
Enforce required fields before transitions.
Example:
Before “Ready for QA”: PR Link, Test Cases
Before “Done”: Time tracked, checklist completion
Context-Based Permissions
Different rules per Space/Folder/List.
Example:
Engineering: Devs can edit Due Dates
HR: Only HR Managers can edit Due Dates
Role & Assignment-Based Permissions
Only Assignees can update progress, time tracking, or move tasks from “In Progress”.
Only Reviewers can approve/reject in QA stages.
Field Locking by Status
Auto-lock fields based on status.
Example: Lock estimates after “In Dev”, lock Due Date after QA.
Audit & Override Control
Track changes to critical fields. Allow overrides only for Admins with logs.
View & Filter Restrictions
Restrict users from editing views or creating new ones unless allowed. Ensure standard views remain controlled.
Controlled Visibility (Me Mode Enforcement)
If a user has access to a List but is restricted, they should only see tasks assigned to them (“Me mode”).
Users should NOT be able to remove this filter or view all tasks.
Conditional Private Views
Users can create private views only within enforced filters.
Example: If “Assignee = Me” is enforced, private views can only be created on those tasks, not the full dataset.
Admin-Enforced Default Views
Admins can define non-editable default views as the source of truth.
Why this matters:
Ensures data security, prevents unauthorized changes, enforces structured workflows, and enables enterprise-grade governance in ClickUp.
Franziska Tryzna
Armine Seropyan Looking forward to this, our use case at the moment is mostly preventing specific user groups from adjusting the status of tasks while maintaining edit permissions for custom fields etc.
We'd love to join the beta once available.
J
Joseph Plaizier
Armine Seropyan Thanks for the update! That is good news! Our current use case is we have one workspace (department) that is used across 4 teams (divisions). Each of those teams has their own groups that perform different job functions. On top of that, we have users outside of our department completely that request access to sometimes edit, sometimes comment, and sometimes view only different tasks and other users who are outside of our organization.
Each of them has their own way of doing work and using ClickUp and each of them needs to be restricted in what they can and cannot do. The current permissions sets are too broad.
We need to be able to identify who can edit fields, change statuses, create fields, delete fields, view fields, create lists, delete lists, move lists, move tasks, add tasks to lists, use AI, use agents, connect third party apps, connect clickapps, connect email, comment, etc. It would be wonderful if there were more details about what Admins can or cannot control/manage (I have seen a few other replies already about this).
Perhaps out of the scope of this request, but it would also be nice if a limited-member/guest could comment on a task and not have it require a license.
It's nice to see that ClickUp is making changes and pushing forward with innovation to take it from being a small teams app to an enterprise app. At least taking steps anways.
We're looking forward to this and look forward to the beta.
Andrew Tomassetti
I see that this feature request is being is in "Building Now". Will that include permissions to associate things like:
- views - sharing views with members instead of all views in a list? This is a big one as we may have 30+ views on a list and bring on a limited member and ideally we'd like to share a single view so filters and everything are set up correctly and no issues with defaulting to another list causing confusion.
- assigned tasks - a permission to have a user only be able to see tasks assigned to them would be fantastic. Sure there are permissions for users not being able to delete, however we should be able to block visibility completely, WITHOUT requiring to make every task private.
Matthew Burt
I was sent here by the AI chatbot, but this looks like a fundamental design flaw, not a feature request.
Here’s the issue: I assign a user Admin with all admin permissions enabled, including custom field permissions and the explicit ability to edit custom fields. Then, on specific custom fields, I set them to view-only because I don’t want general staff editing them.
Result? My Admins can’t edit them either.
In what world is this “working as intended”? The entire purpose of an Admin role is to override restrictive user-level permissions. If a field-level toggle can silently nullify Admin permissions, then “Admin” isn’t actually an override—it’s just another role with arbitrary limits.
The proposed workaround makes this worse: manually open each custom field (even if you have 100+), check whether it’s view-only, and then explicitly add Admin users by name and grant edit access one-by-one. And let’s be clear—this mechanism isn’t Admin-specific at all. Once a field is view-only, I can grant edit access to any individual user the same way.
So what exactly does the Admin permission level do here? Because in many real-world cases, it does nothing meaningful.
If field-level permissions are intended to supersede Admin, that needs to be explicit and intentional—ideally with an option like “Allow Admin override.” As it stands, this setup defeats the core expectation of an Admin role and creates unnecessary operational friction at scale.
Armine Seropyan
Merged in a post:
Role-Based Custom Permissions for each Space (not just the Workspace)
Looking to create & set role-based Custom Permissions that can vary from Space to Space.
For instance, a Marketing VP should have admin-like Custom Permissions in their Marketing Space, but should not have the same level of capabilities/control in an HR, IT, or Finance Space.
Role-based Custom Permissions are currently available on the Workspace level -- bringing this functionality down to the Space level would be invaluable, especially for larger/more complex Workspaces!
Armine Seropyan
Merged in a post:
More granular permissions
Marek Dziedzic
We need a permission that is between "edit" and "full". Basically, we want to support the following condition:
Ability to create new tasks, modify existing tasks, and move them around with in a list/folder/space but NOT be able to modify other permissions, edit views, create new fields, modify other user's permissions etc.
The use case is that we have a group of admins/leaders who have built out the spaces, and we have users that need to now "use" the spaces (creating tickets, running projects, etc.) but should not be able to touch the overall configuration.
N
Neil Hogan
Yep! And please review some of the permission settings available on the business plan! this really should be more generous.
Load More
→