Skip to main content

Admin guide · Organization

Teams

A team is a named group of people and nothing else. It owns no keys, no models and no budget — its only purpose is to be handed a role on a project as a block, so that joining the team is what grants access. Manage them under Admin → Teams.

The teams list

Every team with its size and how many projects it has been given a role on.

The Teams admin page: a table of teams with their member count, project count and a delete action, plus a New team button.
Admin → Teams — the two numbers that say what a team is for.

New team only asks for a name; you add people afterwards. Deleting a team removes it from every project roster it was on — the people stay in the organization and keep any access they hold by other routes.

Renaming and membership

Opening a team gives you its name and its roster. That is the whole surface.

A team's detail page with an editable name field and a members table. Names and emails are redacted.
A team — a name and a list of people (names and emails redacted).

People are added from the organization roster, so someone has to exist as a user before they can join a team. Adding them here grants, immediately, every project role the team holds; removing them takes those away again, and nothing else.

note · Teams carry no role of their own

There is no “team role”. The role lives on the project roster entry — the same team can be Admin on one project and Viewer on another. Which is also why a team page shows no permissions: there is nothing to set here.

Why a team can show 0 projects and still appear on one

The two surfaces count different things, on purpose.

  • Projects on this page counts the rosters the team was added to as a team. It is the access the team grants.
  • The team badges on the Projects list are wider: they also include the teams of the individual people on the roster. They answer “who works on this?”, not “who granted it?”.

warning · A badge is not access

Adding a person to a team never retro-grants them the projects they already reach personally, and their team appearing as a badge there does not give the rest of that team anything. If you want the team to hold the access, add the team to the project roster.

When to use a team

Teams are a convenience, not a security boundary — the boundary is the project role.

Reach for a team when the same group needs the same role on something more than once, and the group changes more often than the projects do — an on-call rotation, a squad, a partner agency. One person who needs one project is faster to add directly.

tip · Overlaps resolve predictably

Someone reaching a project through two teams gets the widest of those roles. Adding them to the roster personally overrides the lot, in either direction — see Members & project roles.