Organizations, projects, and members

The Convoy access model — organizations, projects, roles, aliases, and invitations.

Convoy has two access scopes that work together: the organization and the project.

Organizations

An organization is the top-level container for people, projects, and administration. Use organizations to model companies, teams, client accounts, or environments.

Organizations are where membership is managed centrally: people are invited into the organization first, then granted access to projects inside it.

Projects

Projects are where work happens. A project contains tasks, AI threads, members, permissions, and CLI profile connections.

Each project has two identifiers:

a slug — URL-friendly, used in web app routes
an alias — a short uppercase code (2–5 characters, e.g. WEB) used to generate task refs such as WEB-42

Keep aliases short and stable: they appear in every task ref, commit message, and CLI command that touches the project.

Roles and permissions

Permissions are enforced at both levels, by the backend rather than just the UI:

Organization owners and admins have implicit broad access to all projects in the organization.
Project members can be scoped to individual projects without org-wide rights.

In practice: use organization roles for the people who administer the workspace, and project membership for everyone else.

Invitations

Members are invited by email. When transactional email is configured, invitation and project-add notifications are delivered through Resend; invitation links target the deployed app URL.

Why this matters for AI workflows

Project membership is also the trust boundary for AI execution: anyone who can send a thread message in a project can drive the agent running on a connected teammate's machine. See the Security model before connecting a CLI profile to a project with a broad membership.

Tasks
AI threads
API keys — keys inherit exactly these permissions