Nested groups

A group can be a member of another group. This lets you model your organization the way it really is: teams inside departments, departments inside divisions. Membership flows upwards: whoever belongs to a team also belongs to the department that contains it.

An example

Your engineering department has two teams. You create three groups and add “Backend” and “Frontend” as members of “Engineering”:

Engineering
├── Backend        ← group, direct member of Engineering
│   ├── Ana        ← direct member of Backend, indirect member of Engineering
│   └── Bruno
├── Frontend       ← group, direct member of Engineering
│   └── Carla
└── Diego          ← direct member of Engineering

The result:

• Ana, Bruno and Carla are indirect members of “Engineering”: they belong to it through their team.
• Diego is a direct member of “Engineering” only.
• An application assigned to “Engineering” is available to Ana, Bruno, Carla and Diego.
• An application assigned to “Backend” is available to Ana and Bruno only.

When Ana joins the company, adding her to “Backend” is enough: she automatically gets everything “Engineering” gives. When she moves to the frontend team, move her from “Backend” to “Frontend” and her access follows.

Direct and indirect members

In a group’s Members tab, the Assignment column tells the two apart:

• Direct: added to this group explicitly.
• Indirect: belongs to this group because it is a member, at any depth, of one of its member groups.

Nesting can go as many levels deep as you need: if “Engineering” is itself a member of “Technology”, Ana is also an indirect member of “Technology”. Check Show only direct associations to see only what was added to the group explicitly.

A member can belong in several ways

The same person can belong to a group in more than one way: directly and through a team, or through two different teams. BreezeAuth keeps track of every path. They remain a member, and keep the group’s access, as long as at least one path remains.

For example, if Diego is a direct member of “Engineering” and is also added to “Backend”:

• removing him from “Backend” leaves him in “Engineering” as a direct member;
• removing his direct membership in “Engineering” leaves him in “Engineering” as an indirect member, through “Backend”.

Removing members

Only direct members can be removed from a group. To end an indirect membership, act where it comes from:

• remove the person from the member group they belong to (Ana from “Backend”), or
• remove the member group itself from the group (“Backend” from “Engineering”). All of that group’s members stop being indirect members, unless they belong in another way.

Rules

To keep the structure consistent, BreezeAuth refuses changes that would create a loop:

• a group can’t be added to itself;
• a group can’t be added to one of its own members, at any depth. If “Backend” is in “Engineering”, “Engineering” can’t be added to “Backend”, nor to any group inside “Backend”.

Effect on application access

Indirect members get the same application access as direct members. When someone signs in to an application, BreezeAuth considers every group they belong to, directly or indirectly. See Application access.

This also works the other way round: the Assigned applications tab of “Backend” lists only the applications assigned to “Backend” itself, but its members also have access to the applications assigned to “Engineering”, the group that contains it.

Effect on webhooks

If you use webhooks, BreezeAuth sends a group_assignment.created event for every new membership, including indirect ones. Adding “Backend” to “Engineering” sends one event for “Backend” joining “Engineering”, and one for each member of “Backend” who becomes a member of “Engineering”. The same applies to group_assignment.deleted when memberships end.

No event is sent when a membership only changes from direct to indirect, or the other way round, because the member still belongs to the group.

Good practices

• Keep it shallow. Two or three levels, such as division › department › team, are usually enough and easy to reason about.
• Put people in the most specific group. Add Ana to “Backend”, not to both “Backend” and “Engineering”. She already belongs to “Engineering” through her team.
• Assign applications at the right level. Applications everyone in a department needs go on the department group; team-specific tools go on the team group.