Get started
Workspaces & teams
How workspaces, teams, and team keys are organized — and how membership maps to what people can see.
Last updated
A workspace is the top-level container for your company's work. Inside a workspace you create one or more teams; each team owns its own issues, boards, cycles, and (optionally) projects. This mirrors how most companies are organized: a workspace per company, a team per squad.
Team keys and issue identifiers
Every team has a short, uppercase key — ENG, DES, SUP. Issues are numbered sequentially within their team, producing stable identifiers like ENG-1042. The identifier never changes, even if the issue moves between projects or cycles, so you can paste it into a commit message, a Slack thread, or a PR title and it always resolves.
Membership and visibility
Members belong to a workspace and can be added to specific teams. What a member can read and write is enforced at the database layer with row-level security, not just in the UI — see Permissions & RLS for the full model. This means an API token or an integration is bound to the same tenant boundary as the person who created it.
When to add a team vs. a project
Add a team when a distinct group owns a distinct stream of work with its own board and cycle cadence. Use a project (inside a team) for a scoped piece of work with a clear start and finish — a launch, a migration, a quarter's theme. Initiatives group projects across teams when you need a roadmap above the team line. Concepts → Data model covers how these relate.
Related
- QuickstartCreate a workspace, invite teammates, and create your first issue — the five-minute path from sign-up to a working board.
- Data modelHow workspaces, teams, issues, projects, initiatives, and cycles relate — one schema underneath every view.
- Permissions & RLSTenant isolation enforced in Postgres with row-level security — the same boundary for the UI, the API, integrations, and AI.