Workspaces, projects, and tasks

Three levels, strictly nested — nothing is shared across workspaces.

Workspace

The top-level container. It has a name, a unique handle, and its own billing, members, statuses, and labels — nothing at this level is shared with any other workspace. Every workspace has exactly one Owner, fixed to whoever created it, with two powers nobody else gets: deleting the workspace and managing billing.

Project

A body of work inside a workspace, with its own team, tasks, labels, and milestones. A project can be private — visible only to the people added to it — or open to the rest of the workspace. Archiving or deleting a project is recoverable for a grace period before it's gone for good.

Task

A single unit of work inside a project. Tasks are flat — no subtasks, no sections, no parent-child trees. If a task feels too big, split it into two tasks.

Roles

Two separate sets of roles — one per workspace, one per project — and they don't inherit from each other automatically.

Workspace roleCan do
OwnerEverything, plus delete the workspace and manage billing
AdminEverything except the two Owner-only powers
MemberCreate projects, browse the workspace directory, open any non-private project
External collaboratorNothing workspace-wide — access comes only from project invitations
Project roleCan do
LeadFull control except deleting the project. Given automatically to whoever creates it
PMManage tasks, members, and milestones
DevCreate and work tasks, labels, and statuses
TesterCreate and update tasks, no deleting
GuestCreate tasks, edit only tasks assigned to them, comment

There's no "Owner" project role — the creator becomes Lead.

Who sees what

Access resolves top-down: a workspace Owner or Admin can reach every project regardless of role. A Member who was never added to a non-private project still gets Dev-level access to it by default. A guest sees only the specific projects they were invited to, and nothing else in the workspace.