Help Center / Settings and administration /
Per-entity permissions
Role-level permissions define what each team member can access across the workspace, but per-entity permissions narrow that scope further. A specific project, task board, or task group can restrict access to selected team members, overriding the broader role settings for that item.
How per-entity permissions work
When per-entity access is set on a project, only the team members explicitly added to that project can see it, regardless of what their role allows. The same applies to task boards and task groups within a project. A team member might have general project access through their role, but if a confidential project has per-entity restrictions, that project won't appear in their view unless they're specifically added.
Where per-entity permissions apply
Per-entity access can be configured on three levels:
- Projects: restrict the entire project to specific team members or clients.
- Task boards: limit visibility of a task board within a project to selected members.
- Task groups: hide specific task groups from members who have access to the broader project.
These levels nest naturally. A project might be visible to the full team, but one task board within that project could be restricted to two people, and within that board, a specific task group could be limited to just one.
Role permissions and per-entity permissions together
Per-entity permissions always narrow access, never expand it. If a role doesn't allow viewing projects at all, adding that member to a specific project's access list won't override the role restriction. The role sets the ceiling, and per-entity permissions control which items within that ceiling are visible.
This layered model means broad access rules are handled at the role level, and sensitive or confidential items are locked down at the entity level, without needing a separate role for every edge case.
