Permissions Reference
What each module's access level allows, and how project API keys inherit permissions.
Each module is a permission scope. Its level, No Access, Viewer, or Editor, sets what you can do in that module. Levels come either from a built-in project role or from a custom role.
Access levels
| Level | For most modules |
|---|---|
| No Access | Cannot open the module. |
| Viewer | View and comment. |
| Editor | Everything a Viewer can do, plus create, edit, and manage content. |
What Editor adds, module by module
| Module | Viewer | Editor adds |
|---|---|---|
| Requirements | View and comment | Create, edit, and delete requirements; apply tracked edits; manage links to related items; change the Requirements templates in settings. |
| Blueprints | View and comment | Create, edit, and delete blueprints; manage blueprint code links; manage links to requirements; manage categories. |
| Work Orders | View and comment | Create, update, delete, and assign work orders; manage statuses, labels, and the phase schedule; link themes, requirements, blueprints, and Knowledge Base items. |
| Feedback | View and comment | Create, update, and triage feedback; create and edit themes; link themes to work orders. |
| Knowledge Base | View and comment | Create and edit documents; upload, rename, organize, and delete files and folders; manage relationships. |
| Skills | View and comment | Create, edit, and delete skills; add skill rules; publish skills to the organization; add built-in and published skills to the project and apply updates from their source. |
| Automations | View automations and their run history | Create automations, and edit, enable, disable, and delete their own automations. |
In Feedback, linking a theme to a feature also requires Requirements Viewer access.
Automations are the one place Editor access does not extend across other people's work. An Editor manages only the automations they created. Editing or deleting someone else's automation is an Owner action, which organization Admins hold through their automatic Owner access.
Attachments and the Knowledge Base library
Anyone who can open a project can attach new files to comments, documents, and agent messages, even without Knowledge Base access. Posting the comment, editing the document, or sending the message still needs permission for that action.
Attachments are visible to everyone who can open the project. A project member with a link to an attachment can read, preview, and download it, even without access to the module it was attached in. That doesn't let them browse the Knowledge Base.
To pick existing files from the Knowledge Base, you need Knowledge Base Viewer access. To create documents or upload files into the Knowledge Base itself, you need Knowledge Base Editor access.
Codebase Connection
Codebase Connection uses the same labels with a different meaning:
| Level | Codebase Connection |
|---|---|
| No Access | No access to indexed code, connection settings, or reindexing. |
| Viewer | Search and read indexed code, including through the agent. |
| Editor | Everything a Viewer can do, plus manage the connection. |
The built-in Editor project role can manage the connection but can't reindex the codebase. Reindexing is an Owner action. The exception is a custom role that sets Codebase Connection to Editor, which can also reindex.
See Codebase Connection for setup.
Project API keys
Project API keys let external tools call a project through the API.
- Viewers can create keys. Any project member who can view the project can create a project API key and see the project's keys, with their values hidden.
- Keys are project-scoped. Each key belongs to one project. External API keys start with
sofa-ext-, and Feedback Integration keys start withsf-rpt-. - A key acts as its creator. Requests made with a key authenticate as the person who created it and inherit exactly that person's permissions, never more.
- A key follows its creator's access. If the creator leaves the organization, requests fail with "API key owner no longer has access to this organization". If the creator loses their project role, requests are denied just as the creator's own requests would be.
- Renaming or deleting a key requires the key's creator or a project Owner. Organization Admins qualify through their automatic Owner access.
Next, learn about View seats.