Roles & Permissions

Comvi uses a role-based access control (RBAC) system to manage what each team member can do. Roles are assigned at the organization level and can be overridden per project for fine-grained control.

Two ways to authenticate

Before the matrix, it helps to see how permissions get evaluated at the two entry points into the platform.

flowchart LR
  User["Human user"]
  Dashboard["Dashboard / browser"]
  Session["Session<br/>(cookie, Redis store)"]

  Machine["CLI / CI / automation"]
  Header["X-API-Key header"]
  Key["API key record<br/>(project-scoped, own permissions)"]

  API["Comvi API"]
  PermCheck{"Permission check"}

  User --> Dashboard --> Session --> API
  Machine --> Header --> Key --> API
  API --> PermCheck
  PermCheck -- resolves against --> Roles["Role → permissions"]
  PermCheck -- or --> KeyPerms["API key → permissions"]

Human users authenticate with sessions and inherit their member role's permissions. Machine clients authenticate with an API key that carries its own permission set, independent of any user.

Humans always act through their member role. API keys are a separate identity with their own permission list — they do not inherit from the person who created them. See API Keys for details.

Role Hierarchy

Comvi has five roles, ordered from most to least privileged:

Role	Level	Description
Owner	5	Full control over the organization, billing, and all projects. Cannot be removed.
Manager	4	All project permissions plus organization settings, member management, and project creation.
Editor	3	Create and edit translation keys, namespaces, and import/export content. Cannot manage members or billing.
Translator	2	Edit and create translations, use machine translation, and add comments. Cannot modify keys or project structure.
Viewer	1	Read-only access to projects, translations, glossaries, and history.

Tip

Roles generally expand access as they move up the hierarchy, but a few feature-specific permissions differ by role. Use the matrix below as the source of truth.

Organization Permissions

Organization-level permissions control access to settings, billing, and team management. These are determined by the member’s organization role.

Action	Owner	Manager	Editor	Translator	Viewer
View organization	✓	✓	✓	✓	✓
Edit organization settings	✓	✓
Delete organization	✓
Manage members & invitations	✓	✓
Manage billing	✓
Create projects	✓	✓
Manage glossaries	✓	✓
Edit glossary entries	✓	✓	✓
View glossaries	✓	✓	✓	✓	✓
Manage translation memory	✓	✓
View translation memory	✓	✓	✓	✓	✓

Project Permissions

Project-level permissions control what members can do within a specific project. The following table shows the default permissions for each role.

Action	Owner	Manager	Editor	Translator	Viewer
View project & translations	✓	✓	✓	✓	✓
Edit project settings	✓	✓	✓
Delete project	✓	✓
Import translations	✓	✓	✓
Export translations	✓	✓	✓
Create & edit translation keys	✓	✓	✓
Delete translation keys	✓	✓	✓
Edit translation values	✓	✓	✓	✓
Create translation values	✓	✓	✓	✓
Review / approve translations	✓	✓	✓
Create & edit namespaces	✓	✓	✓
Delete namespaces	✓	✓	✓
Use machine translation	✓	✓	✓	✓
Manage MT settings	✓	✓
Create & edit comments	✓	✓	✓	✓
Delete comments	✓	✓
View translation history	✓	✓	✓	✓	✓
Create API keys	✓	✓	✓
Edit/delete API keys	✓	✓
View API keys	✓	✓	✓	✓	✓
Manage webhooks	✓	✓	✓
View webhooks	✓	✓	✓		✓
Manage project members	✓	✓
Publish to CDN	✓	✓

Project-Level Role Overrides

By default, a member’s project permissions come from their organization role. You can override this on a per-project basis to restrict access for a specific project.

For example, a member with the Manager organization role can be assigned the Editor role on a specific project, letting them edit content there without project-member management or publish permissions.

1. Navigate to the project

   Open the project in the Comvi dashboard and go to Project Settings > Members.

2. Find the member

   Locate the team member in the members list.

3. Set the project role

   Select a role from the dropdown. This overrides their organization role for this project only.

Caution

A project role override cannot exceed the member’s organization role in the hierarchy. For example, you cannot give a Viewer the Translator role on a project. To grant higher access, update their organization role first.

How Permission Resolution Works

When a member accesses a project, Comvi resolves their permissions in this order:

1. Check for a project-level role override — if one exists, use that role’s permissions, capped by the organization role.
2. Fall back to the organization role — if no project override exists, use the member’s org role.

This means a member with the Editor organization role automatically has Editor permissions on every project, unless a project-level override changes that.

Language Restrictions

Translators, Editors, and Viewers can be restricted to specific languages within a project. When language restrictions are set, the member can only view and edit translations for the assigned languages.

Note

Owners and Managers cannot have language restrictions. They always have access to all languages across all projects.

Language restrictions are set per project member in Project Settings > Members. Select the languages the member should have access to, or leave it empty for access to all languages.

Next Steps

• Translation Lifecycle — which transitions each role can trigger
• Team Management — invite members and assign roles
• API Keys — create scoped API keys for integrations
• API Authentication — understand permission scopes in the REST API