Organization teams#

Organization teams group existing organization members so a project role can be granted to the group instead of to each person individually.

For the setup workflow, see Manage organization team access. For a compact role lookup, see Roles and permissions.

Teams are private to organization management. Organization owners and managers can see team membership and project access; public pages do not list teams or reveal team-derived roles.

Teams contain organization members#

A team has an identifier and a display name. The identifier appears in the team management URL and stays stable for links and audit records. The display name is the human-readable label shown to maintainers.

When Sysand Index needs a compact team identifier, it shows the organization and team identifier together, such as @sensmetry:release-team.

For the exact team identifier rules, see Roles and permissions.

A team can only contain users who are already members of the organization. Add people to the organization first, then add their organization membership to a team.

Removing someone from the organization also removes that person from every team in the organization. Any project access they had only through those teams is removed at the same time.

Project access is additive#

A team’s project access gives every current team member a project role. It does not create direct project memberships and does not remove existing direct memberships.

For example, a user can have direct Maintainer access to a project and Owner access through an organization team at the same time. Sysand Index then uses the highest project role, as described in Roles and permissions. If the team access is later removed, the user’s direct Maintainer access remains.

Direct members and team access#

Project member management separates direct members from team access:

  • Direct members are users explicitly invited to the project.

  • Team access comes from organization teams with project access.

Project invitations still create direct project access. This can be useful when one person should keep access even if team membership changes later. You can invite someone who already has only team-derived access; accepting the invitation creates direct project membership that remains if team access later changes.

Use direct project membership when access should belong to one person independently of organization team changes. Use team access when the project role should follow a group, such as everyone currently responsible for releases.

Organization owners add, change, and remove team access from the project’s Members page. The team page is for reviewing that team’s members and the projects the team can access.

Organization owners can administer access for projects in the organization namespace even when they are not listed as project members, but that authority alone does not grant upload or project-token access; see Roles and permissions.

Owner continuity#

Every project must keep at least one effective Owner, and Sysand Index blocks team and membership changes that would leave a project without one. For the complete list of blocked changes, see Roles and permissions.