Team Management

Members are the humans on your team. Each one has an organization-level role, optional project-level overrides, and optional language restrictions. Picking the right combination keeps everyone seeing what they need and nothing else.

This page is scenario-driven. For the exact permission matrix, see Roles & Permissions.

Inviting a member

1. Open members

   Organization Settings → Members.

2. Invite

   Click Invite Member. Enter their email and pick an organization role (see the role cheat sheet below).

3. Scope access (optional)

   • Leave blank for organization-wide access.
   • Scope to one or more projects to override their org role there.
   • Scope to specific languages within a project if they should only work on those.

4. Send

   They get an email with a join link. You can resend or cancel it from the members list.

Tip

Invite several people at once with different roles and scopes. Each invitation is independent.

Role cheat sheet

Role	Edit translations	Edit keys / settings	Manage members	Publish
Owner	✓	✓	✓	✓
Manager	✓	✓	✓	✓
Editor	✓	✓	—	—
Translator	✓	—	—	—
Viewer	—	—	—	—

Full matrix: Roles & Permissions.

How access is resolved

When a member opens a project, their effective role is picked in this order:

1. Explicit project-level role for this project, if any.
2. Organization default — depends on your organization’s default project access setting (role_based, view_only, or none).

Project-level overrides never exceed organization role in privilege — they can narrow access for one project, not raise it. A Manager at the org level can be made Editor on a project, but a Viewer cannot be made Translator.

Language restrictions

Within a project, a member can be restricted to specific languages. The editor still shows other languages for reference but only lets them edit the assigned ones. Owners and Managers cannot be restricted — they always see everything.

Language restrictions live on the project membership, not the org membership. Set them in Project Settings → Members.

Scenarios

Small in-house team

Two developers, one PM, no dedicated translators yet. One organization, one project.

• Developers: Editor at the org level
• PM: Manager at the org level
• Default project access: role_based (the default)

When you hire a translator, invite them as Translator with a language restriction.

Adding a freelance translator

You have a French translator on a short contract. You don’t want them to see anything except French strings in your web-app project.

1. Invite them as Translator at the org level.
2. In Project Settings → Members for web-app, restrict them to fr.
3. For other projects, either don’t add them (if the org default is none) or rely on the language restriction alone.

When the contract ends, remove them from the organization. Their comments and history stay attributed to their account.

Agency managing client projects

You run Comvi for multiple clients. Each client is its own organization for hard isolation. Within each:

• Your staff: Manager at the org level
• Client stakeholder: Viewer at the org level, so they can see progress
• External translators: Translator with language restrictions per project

Set the organization default project access to role_based for your staff or none if you want to hand-pick each project assignment.

Splitting translators and reviewers

You want a review step: translators write, someone else approves.

• Translators: Translator role — they can write values but cannot mark Translated.
• Reviewers: Editor role — they can move values to Translated.
• Developers and managers: Manager or Editor as appropriate.

See Translation Lifecycle for what each status means and who can trigger each transition.

Read-only stakeholder

A product manager or legal reviewer who needs visibility but must not edit anything.

• Invite as Viewer at the org level.
• If you use role_based default project access, they see every project read-only. If you use none or view_only, add them explicitly to the projects they need.

Managing existing members

Change a role

Organization Settings → Members → role dropdown. Takes effect immediately.

Revoke or resend an invitation

Pending invitations appear in the same list. You can Resend (fresh email, same expiry) or Cancel before acceptance.

Remove a member

Organization Settings → Members → Remove. They lose access to every project immediately. Their history, comments, and audit entries remain attributed to their account for the audit trail.

Caution

Owners cannot be removed by anyone except another Owner. Make sure there is always at least one other Owner before transferring the role.

Organization member vs project member

Layer	Scope	Set by
Organization member	Belongs to the org; gets default project access per the org setting	Owners, Managers
Project member	Explicit project-level role and optional language restrictions, overriding the default	Owners, Managers, project Managers

A person must be an organization member before they can be added to a project — there is no way to grant project access to a non-member.

Limits

• An Owner must always exist. The last Owner cannot remove themselves or demote themselves without transferring first.
• Language restrictions apply only to Translator, Editor, and Viewer roles. Owners and Managers always see all languages.
• Project-level roles cannot exceed organization roles in privilege.

Related

Roles & Permissions Exact permission matrix and override rules.

Translation Lifecycle Who can move a value through which status.

API Keys Machine credentials for CLI, CI, and automation.