Groups

A group is a named set of people, such as Finance or Platform Engineering. Groups do two jobs: they hold access, so it can be granted to a team rather than a list of individuals, and they own Deployables, so work belongs to the team rather than to whoever created it.

Creating a group requires the creator or admin role. A group has members and one or more owners.

Why use them

Access stays correct. Someone joining Finance gets every tool shared with the Finance group, and loses them on leaving. Individual grants quietly become wrong instead.

One change, many tools. A team of eight with a dozen tools is ninety-six grants to maintain, or one membership.

Ownership outlives people. A Deployable owned by a group is managed by the group’s owners, so it still has a maintainer after its author changes teams.

Access becomes reviewable. “The Sales group” is an answer. A list assembled ad hoc over a year is not.

Public and private

A public group can be seen by the organization. A private group’s membership isn’t readable by people outside it.

Owners add members directly, and people can ask to join, which an owner accepts or rejects.

Designing them

Mirror how work is organized rather than the org chart. Prefer a few durable groups to a group per project, which becomes an unmaintained list once the project ends. Name them for who they contain (Finance), not what they can do (Can view the budget dashboard), which becomes a lie on second use. Keep at least two owners, so the group isn’t stuck when one person is away.