Restrict Status based on permissions
Log In
João Ribeiro
That was supposed to be ready guys, very important!
Caroline Ginty
Merged in a post:
TASK STATUS PERMISSIONS
Domel Perez
Is it possible that in Board view Status we can assign permissions to view each status.
I wanted to know whether we set status based permission(Users), like, Review(status) need to be restricted to certain users.
D
Dorothy Pacanza
This functionality is very important to us.
Andrea Feicán
Currently, any user can move tasks to any status, which often causes skips in the workflow, confusion in reporting, and unnecessary rework. Having the ability to restrict or define allowed status transitions would help keep processes consistent and reliable.
Armine Seropyan
Andrea Feicán: Thank you for feedback here. To help us scope this out properly, I had a couple of quick questions:
- Role-based vs. user-specific restrictions— Would limiting status changes by role (e.g. Manager, Member) work for your team, since this would apply universally across the workspace? Or would you need something more granular where you could restrict specific users regardless of their role — for example, blocking a particular person based on their permission leefrom closing tasks even if they're a Manager?
- Scope of the restriction— Would a workspace-wide rule be sufficient, or do you need the ability to set different rules depending on the Space, Folder, or List you're working in?
Andrea Feicán
Armine Seropyan: Hi, thank you for the follow-up questions.
- Role-based vs. user-specific restrictions
Ideally, this functionality should not depend solely on user roles.
In practice, users with the same role (for example, managers) may require different levels of action depending on the workflow they are involved in. A user with a higher-level role might only need to intervene in specific stages (such as approving or rejecting) but should not necessarily have permission to move tasks to other states outside of their designated stage.
For this reason, it would be more appropriate to allow transition restrictions to be configured per specific user or authorized group for each state, independently of their general role within the workspace.
- Scope of the restriction
It would not be necessary for this rule to apply universally across the entire workspace.
The most useful approach would be to allow configuration at the Space, Folder, or List level, since different teams and workflows may require different levels of control. Some workflows may remain flexible, while others require a strict state sequence.
General functional objective
Currently, any user can move tasks to any status, which can result in:
Workflow jumps
Reporting inconsistencies
Loss of traceability
Incorrect automation triggers
The ability to define allowed state transitions (for example, restricting that from a given status tasks can only move to specific next statuses and only by authorized users) would:
Ensure process consistency
Maintain workflow integrity
Improve reporting reliability
Reduce the need for additional manual controls
I believe this functionality would significantly strengthen governance and process reliability across structured workflows within the workspace.
Caroline Ginty
Merged in a post:
Limit Task Status Changes by User or Role
Riley Dickerson
Currently, any user with edit access to a task can change its status to any available option. For better workflow control and accountability, it would be extremely helpful to restrict which users or roles can move tasks to specific statuses.
For example, I want my team to be able to move tickets from “To Do” to “In Progress,” but only managers or leads should be able to move tickets to “Closed” or “Done.” This would prevent tasks from being closed prematurely and ensure proper review and approval before completion.
This would allow admins to set permissions for which users or roles can move tasks to specific statuses. For even more granularity, it would be great if we could allow status change restrictions to be set at the Space, Folder, or List level, and Ideally provide an override option for workspace owners/admins.
This feature would improve quality control, accountability, and process compliance for teams that require strict review or approval steps before closing tasks. This would complement the Approvals custom field and advanced permissions, but provide more granular control over workflow transitions.
T
Tomáš Brokeš
yes this is must have
Taras Kozak
In ideal world it could be an Advanced section in Statuses Modal to set all legal transition bi-directional graph (to excluse illegal arrows from all-to-all connection/direction) and required permission to do legal transition between statuses (who can change status for every arrow).
In this case you can block transition from "DEVELOPMENT" to "PRODUCTION" status skipping "TESTING" one.
Armine Seropyan
Taras Kozak: Thank you for feedback here. To help us scope this out properly, I had a couple of quick questions:
Role-based vs. user-specific restrictions — Would limiting status changes by role (e.g. Manager, Member) work for your team, since this would apply universally across the workspace? Or would you need something more granular where you could restrict specific users regardless of their role — for example, blocking a particular person based on their permission leefrom closing tasks even if they're a Manager?
Scope of the restriction — Would a workspace-wide rule be sufficient, or do you need the ability to set different rules depending on the Space, Folder, or List you're working in?
T
Test
I also need this
Tim Muller
Need this.
Beth Tidwell
Agreed! Would be very useful.
Load More
→