Roles, permissions, and need-to-know
Introduction
Sutram controls access at two complementary levels:
- Project roles — what each person can do in the project as a whole (navigate, create, configure).
- Need-to-know — who sees what in governed content, where visibility depends on the role in the class and the state of the document.
Understanding both prevents surprises — from "why can't I publish?" to "why don't I see this document?".
The four project roles
| Role | In one sentence |
|---|---|
| Owner | Full control, including what is sensitive (roles, access log, settings). |
| Admin | Day-to-day management delegated by the owner (members and their basic roles, schema, governance). Available on the Max plan. |
| Member | Creates and edits content. |
| Viewer | Reads the content and participates in comments and chat, but does not edit. |
The Admin role can only be assigned in projects on the Max plan. On other plans, the available roles are Owner, Member, and Viewer.
What each role can do
| Action | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| Navigate, search, read, and download content | Yes | Yes | Yes | Yes |
| Comment and use the project chat | Yes | Yes | Yes | Yes |
| Create/edit content, folders, and uploads; move items | Yes | Yes | Yes | No |
| Version files (checkout, checkin, publish, create version) | Yes | Yes | Yes | No |
| Force-release another user's lock | Yes | Yes | No | No |
| Create and edit records | Yes | Yes | Yes | No |
| Define categories and metadata definitions (schema) | Yes | Yes | No | No |
| Graduate classes and edit lifecycles (governance, Max plan) | Yes | Yes | No | No |
| Invite and manage members | Yes | Yes | No | No |
| Change a member's role | Yes | Yes* | No | No |
| Designate someone as Admin | Yes | No | No | No |
| View the activity log (write audit) | Yes | Yes | No | No |
| View the access log (read audit) | Yes | Yes | No | No |
* The admin changes roles only between member and viewer. They do not promote anyone to admin, nor touch the role of another admin or of the owner — those changes stay with the owner. The owner role is not assignable: it changes only through transfer of ownership of the project.
For the step-by-step of inviting people and assigning roles, see Projects and Members.
The principles behind the table
Instead of memorizing the table, keep the logic:
- Reading is open to every participant — any active member, including the viewer, navigates, searches, and downloads common content.
- Writing content requires an editing role — creating, editing, moving, and versioning are for owner, admin, and member.
- Configuring the project is for owner and admin — record schema, governance, and member management.
- The top of the chain is owner-only — backing up the project, transferring ownership, deleting the project, and inviting an admin stay with whoever has the final say.
- Auditing is for those who administer — both logs, the activity log (who wrote what) and the access log (who read what), are open to owner and admin.
- Participating is an exception to the write rule — commenting and chatting are considered read-adjacent: they are open even to the viewer, because feedback is not a content-editing privilege.
Project roles × class roles
Be careful not to confuse two types of "role":
- Project roles (owner, admin, member, viewer) — are general and apply to the entire project.
- Class roles (e.g., author, reviewer, approver) — exist inside a Document Class and define who acts at each stage of the governance flow.
The same person can be a "member" of the project and an "approver" in a specific class. See Document Classes and Governance.
Need-to-know: visibility by necessity
For common content, the rule is simple: if you participate in the project, you see it. Governance adds a layer of confidentiality by necessity (need-to-know), in two degrees:
- By class — in the Governed Content space, owner and admin see all Document Classes; members and viewers see only the classes where they have a role.
- By state — within a class, the role × state matrix defines, for each state of the lifecycle, who can read and who can write. A missing (state, role) pair means no access.
In practice, this allows a document under preparation to be invisible to those who should only see it after approval — confidentiality follows the document's stage.
Remote access (MCP) and roles
Access via the MCP Server respects exactly the same permissions:
- Viewers connect, but with a read-only surface — the content-writing tools are hidden and denied; comments and chat remain available.
- Writing content, versioning, managing schema, and governance follow the same roles described above.
See Connecting Sutram to Claude and the Sutram MCP Server Guide.
Frequently Asked Questions
Q: Why can't I add an Admin?
A: The Admin role can only be assigned in projects on the Max plan. On other plans, use Member or Viewer.
Q: Can a Viewer comment?
A: Yes. Commenting and using the chat are participation actions, open to any active participant — including viewers. What the viewer cannot do is create or edit content.
Q: Who can change another person's role?
A: Owners and admins can invite participants to a project and change their roles. Only the Owner can designate a participant as Admin — the admin only moves people between member and viewer, and does not change the role of another admin. The Owner's role changes only if project ownership is transferred.
Q: What is the difference between a "project role" and a "document class role"?
A: The project role applies to everything (owner, admin, member, viewer). The class role (author, reviewer, approver…) exists inside a Document Class and defines who acts at each stage of the governance flow.
Q: Why can't I find a document that I know exists (or should exist)?
A: It is probably governed content under need-to-know: you do not have a role in that class, or the document is in a state whose read access does not include your role.
Document Version: 1.0 Last Updated: July 2026 Author: Sutram Development Team