Groups

A group is an organizational label — Engineering, HR, Sales, On-Call. You create groups, put people in them, and use them to address announcements and to filter the Users roster.

A group is not a role

This is the distinction to get right, because the two look similar in the admin UI and do entirely different jobs.

Groups grant nothing. A group carries a name, a description and a membership list — and no permissions of any kind. That is enforced in the database rather than by convention: the groups table has no permission columns at all, deliberately unlike the roles table beside it. Putting someone in a group cannot widen what they can see or do.

So the question "should this be a group or a role?" has a clean answer. If you are deciding what someone may do, that is a role, and a person has exactly one. If you are describing who someone is — which team, which rota, which office — that is a group, and a person can be in several at once.

Creating and managing groups

Managing groups needs the Manage users permission (canManageUsers) — the same permission as adding a person or changing their role. There is no separate group permission to grant.

From the groups view you can create a group, rename it, edit its description, delete it, and add or remove members. Members can also be assigned:

• from a user's row on the Users roster,
• when inviting or adding someone, in the same modal,
• in bulk, to several people at once.

The Users roster can be filtered by group, and each user row shows the groups that person belongs to.

Announcements

A group is a first-class audience for an announcement, alongside a role and an individual user. Addressing a group sends to whoever is in it at the time the announcement goes out.

Groups and SCIM

If your identity provider syncs groups, see SCIM provisioning. One rule matters more than the rest: an IdP may only modify groups it created. A group you make by hand in Strata is administered in Strata, and an IdP write against it is refused. Let the IdP create the groups it intends to manage.

Two places groups deliberately do not appear

These are refusals rather than gaps, and both are deliberate.

The audit log does not record group membership as a column. The audit log is a tamper-evident hash chain: once a row is sealed, changing it breaks every hash after it. Groups are mutable, so stamping today's group onto a sealed row would make that row assert something that quietly stops being true. Group changes are recorded as their own audited actions instead — a group being created, a member being added — which stay true because they describe an event rather than a state.

The Knowledge Base is not scoped by group. Knowledge Base sources are organization-wide. Scoping them by group would turn groups into access control, which is the one thing the design rules out — see A group is not a role above.

Related

• Managing users — roles, per-user limits and overrides
• Roles and permissions — what a role actually grants
• Announcements — addressing a group
• SCIM provisioning — IdP-managed groups