TEAM & ACCESS

Teams and members

Invite people, organise them into teams, and give a team access to the projects it works on.

Access to a project can be granted to a person, or to a team. Both routes end in the same place — a role on a project — but a team is the one that stays correct as people join and leave.

Project members

The direct route: add someone to a project and give them a role. Four built-in roles ship with the product, and a project can define its own — see roles and permissions.

Managing members needs members:manage, which project administrators and owners hold. It is not delegable to a custom role: someone who can add members can add themselves an accomplice, so it stays tied to administrative rank rather than to a permission grid.

Teams

A team is a named group of people, with a colour, owned by whoever created it. You attach a team to a project with a role, and every member of that team gets that role on that project:

TEXT

Team "Backend"   → project "api-prod"     as DEVELOPER
Team "Backend"   → project "api-staging"  as DEVELOPER
Team "Contractors" → project "client-site" as VIEWER

The payoff is one place to change. Someone joins Backend and reaches every project Backend works on; someone leaves and loses all of them at once. The alternative — the same person added by hand to eleven projects — is eleven chances to forget one on the day they leave.

Teams pay off around the third project. Below that they are ceremony; above it, hand-maintained membership lists start drifting silently, and the drift is always in the permissive direction.

Who controls what

Two distinct authorities, and keeping them apart is the point:

Action	Who
Create a team, rename it, add or remove its members, delete it	The team’s owner.
Attach a team to a project, choose its role there, detach it	Someone with `members:manage` on that project.

A team owner cannot grant their team access to your project, and you cannot change who is in their team. Either alone would be a way to acquire access nobody granted — one by pushing a team into a project, the other by pulling people into a team that already has one.

Deleting a team detaches it from every project it was attached to. Everyone who reached those projects only through that team loses access immediately. Check the team’s attachments before deleting it.

Platform administrators

Everything above is per project. Separately, the install has global roles — the people who reach Admin: servers, platform configuration, the license, the fleet-wide audit trail.

An administrator does not have to be a full one. A scoped sub-admin holds exactly the sections you grant — a support desk that can reset passwords but touch nothing else, an infra operator with servers and monitoring and no user authority. See roles and permissions.