Module 3 — People, Clients and Deals · Lesson 3.2
Roles, Permissions and Project Access
Two independent layers, and the one that causes every 'I can't see it' message
~11 min
What you'll learn
- Distinguish the workspace-role layer from the per-project access layer
- Grant and revoke project access from the Team tab
- Diagnose a visibility problem in the right order
- Design access for a workspace holding both client and internal work
Almost every access question in Kavanah resolves to the same confusion: someone assumes one permission system where there are two. They are genuinely independent, they compose, and once you can hold both in your head the answers are immediate.
Layer one: the workspace role
Owner, admin, member. This layer decides what you can CONFIGURE.
Admins configure the workspace: integrations, agent settings and autonomy ceilings, permissions, custom statuses and properties, API keys, directory sync, billing, the KVN charter, deal-room stages and cadences, and the opt-in agent features.
Members do the work: tasks, comments, time, chat, and the agent within whatever ceiling admins set.
Owner is admin plus the workspace-ending operations.
Role is managed from People, and the per-feature detail is on Settings → Permissions.
Layer two: per-project and per-task access
This layer decides what you can SEE.
Every project has a Team tab listing who has access to it. A workspace member who is not on that list does not see the project — it is absent, not greyed out. Tasks can carry their own access lists too, for work that is sensitive within an otherwise open project.
The two layers do not imply each other. An admin is not automatically on every project. A person on every project is not an admin. That independence is what makes it possible to have a contractor who sees exactly one project, and an ops person who configures the workspace without reading the client work.
One detail worth knowing because it has bitten before: a grant has to be a real membership record, not just a name in a list. If someone appears in a project's roster but cannot see anything, the grant did not attach to their account — remove and re-add them by their actual member identity rather than by typed name.
Diagnosing visibility in the right order
When someone says they cannot see something, ask three questions in this order.
One: are they in the right workspace? The switcher is at the top of the sidebar. This resolves more reports than the other two combined, especially for people who belong to several.
Two: are they on the project? Open the project's Team tab. This is the second most common answer by a wide margin.
Three: is it a role thing? Only reach here if the first two are fine. Symptoms that point this way look different — the person can see the page but a control is missing, rather than the page being absent.
Doing it in this order takes a minute. Doing it in the other order means you start by editing permissions, which is both slower and how workspaces end up with everyone as an admin.
One workspace, client and internal work
The common real-world shape is an agency or consultancy that wants client engagements and internal projects in the same workspace, without a client-adjacent person seeing internal strategy.
The pattern that works: one project per engagement, per-project access limited to the people on that engagement, and internal projects that client-facing contractors are simply not on. The workspace role for contractors stays member.
For clients themselves, do not use workspace membership at all — that is what the client portal is for, and it is a separate, deliberately narrower surface covered in the next lesson.
The thing to avoid is the reverse pattern: one big project with everything in it, and an attempt to control visibility task by task. Task-level access exists for exceptions, and using it as the primary mechanism means every new task is a fresh chance to leak.
Set access up properly
- 1
Open a project's Team tab and read who is on it
This is the list that decides visibility. Compare it against who you think should see the project.
- 2
The per-feature role matrix. Worth reading once so you know what admin actually confers before you hand it out.
- 3
Check your admin list is short
People → filter by role. Two or three is healthy; a workspace where most members are admins has no second layer.
- 4
Workspace, then project, then role. Next time someone reports a missing page, resist opening permissions first.
What to watch
- Admin ratio
- Share of members holding the admin role.
- Healthy signal: Small. Our suggested shape is at least two for bus-factor reasons and few enough to name. A high ratio means the role layer has stopped separating anything.
- Orphan members
- Workspace members with access to no project.
- Healthy signal: Zero. Each one is a person opening an empty app, and the fix is one click on a Team tab.
- Task-level ACL usage
- How many tasks carry their own access list.
- Healthy signal: Rare and deliberate. Heavy use means project boundaries are wrong and visibility is being patched task by task.
Key takeaways
- ·Role decides what you can configure; project access decides what you can see. They are independent.
- ·An admin is not automatically on every project, and a project member is not an admin.
- ·Diagnose in order: workspace, then project Team tab, then role.
- ·One project per client engagement, with access limited to that engagement, is the pattern that works.
- ·Task-level access is for exceptions; using it as the main mechanism guarantees an eventual leak.
Next: the other side of the work — clients, contacts, health, and the portal you can let them into.