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, to filter the Users roster, and to lower how much of a model each member may use. By default a group grants nothing, but an admin can bind roles to a group so that every member inherits those permissions.

A group is not a role

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

A group carries a name, a description, a membership list and optional limits that can only lower what its members may spend or use (a group's monthly spend limit caps each member separately, and a member in several groups gets the strictest one; a group can also have one shared monthly budget its members draw on together, set in Usage → Spend limits) — and no permission columns of its own. That is enforced in the database rather than by convention: the groups table has no permission columns, deliberately unlike the roles table beside it. So a group never grants anything by itself. What it can do is carry roles: an admin binds one or more org roles to a group, and every member then inherits those roles' permissions on top of their own direct role.

The mental model still holds: you never hand someone a permission by "assigning a group" the way you assign a role. A person has exactly one direct role (their primary), and any number of groups. Membership is a label; whatever access a group confers comes from the roles bound to it — see Binding roles to a group below.

So the question "should this be a group or a role?" still has a clean answer. If you are describing who someone is — which team, which rota, which office — that is a group, and a person can be in several. If you want a whole team to gain the same set of permissions, bind the role that carries them to that team's group instead of editing each person's direct role.

Creating and managing groups

Creating, renaming, describing, deleting, and populating groups needs the Manage users permission (canManageUsers) — the same permission as adding a person or changing their role. Binding a role to a group is a separate, higher bar: it needs the Manage roles permission (canManageRoles), because it grants permissions.

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.

Click a group to open its page. With View usage & billing, it shows the group's activity over the last 7, 30 or 90 days, and each member's queries, agent runs and credits, ordered by credits used, highest first; without it, the members, most recently added first. The member table shows 100 people at a time: Show more under it loads the next 100 and says how many are not shown yet.

Deleting a group, and adding or removing people in bulk from the Users page, ask you to confirm, and what the confirmation says depends on whether the group has roles bound. With none bound, it treats the group as a label: This applies an organizational label. Their roles and permissions are unaffected. (adding), This removes an organizational label. Their roles and permissions are unaffected. (removing) or <N> members will lose this label. Their accounts and permissions are unaffected. (deleting). With roles bound, it says what they give: They will also get what the role bound to it gives. Their own roles are unaffected., They will lose what the role bound to it gives them. Their own roles are unaffected. and <N> members will lose this group and what its role gives them. Their accounts and their own roles are unaffected. (the N roles bound to it give and its N roles give when more than one is bound). Removing one member with the × beside them in the group's Settings (under Members) asks too, but only when the group has roles bound: Remove <name> from <group>?, with the same message as a bulk removal and Remove from group to confirm. From a group with no roles bound, the × removes them without asking. Deleting a group your identity provider syncs adds Your identity provider will recreate this group on its next sync., or, when it has roles bound, Your identity provider will recreate this group on its next sync, without its roles: bind them again after it returns. Deleting a group removes its role bindings, and the group your identity provider recreates is a new group with none.

Binding roles to a group

Open Organization → Groups, click into a group, and use the Roles section (visible only if your own role grants Manage roles). Pick a role from the dropdown and click Bind; bound roles appear as chips, and a role that grants admin access is tagged admin. Remove a binding with the × on its chip. With nothing bound, the section reads No roles bound — members get only their own direct role.

Binding a role grants its permissions to every current and future member. The fold is grant-only — a bound role can only widen what members can do, never narrow it:

• Admin permissions are OR-ed in: if any bound role grants a permission, every member has it.
• Allowed extensions and allowed AI models are unioned with the member's direct-role lists — a group can add extensions or models but never take them away. A direct role saved with no extensions ticked allows none, so its members get only the extensions and connectors their group-bound roles grant. The union is the same in web chat, the Outlook add-in, Teams, the API and scheduled agents — an agent can run on a model its owner is allowed only through a group. If Strata can't read the owner's groups when a scheduled run starts and the agent's model isn't allowed without them, that run is skipped and tried again 15 minutes later, rather than the agent being paused. Group changes aren't refused over agents; they warn: removing a member from a group (on the group, from the member's Data & sessions tab, or with the bulk Remove from group action on the Users page), unbinding or editing its role, or deleting the group goes through even when a group was the only thing allowing a model one of their agents uses, and the page names the agents the change newly leaves without their model (<N> agents will pause); each is paused the next time its schedule, a webhook or another agent starts it. A change your identity provider makes over SCIM doesn't warn; the agent still pauses, and its owner's inbox says why. The sidebar, the agent form and the Directory use the same union, so extensions a member gets from a group show there too. If Strata can't read a member's extension policy in full, their groups included, those screens hide nothing rather than only what the direct role allows, and the Directory says it could not check; each extension is still allowed or refused when it is used.
• Database access — a member's level on an org SQL connection is the higher of their direct role's Database permission and the highest one among their group-bound roles, so a group can raise it but never lower it. The member's Access tab shows the result under Database access as Role default (Editor) (or whichever level applies). A level picked there for one connection still replaces what their roles give, and Auto-approve database writes follows the direct role only. Which organizations this applies in is described below.
• A member's effective access is always the union of their one direct role and every role bound to a group they belong to, then intersected with org policy and any per-user deny exactly as before.

A group-bound role can also supply a new member's starting values. When their direct role leaves Memory at start or Chat history at start on Organization default, the value comes from their group-bound roles, as long as every one of those roles that sets it agrees; otherwise the organization default stays. Built-in roles never supply one, and a starting value is used once, at the member's first sign-in. See Roles and permissions.

Group-bound roles count toward database access and starting values only in organizations created after this change was released. In organizations that already existed then they don't, so nobody's database access changed when it arrived, and a member's Data & sessions tab says so under Where their permissions come from: Group roles don't change database access in your organization yet.

Changes take effect within about 30 seconds, the session-refresh interval — the same latency as any other role or permission change. A member's sidebar, agent form and Directory catch up without a reload, the next time their Strata tab comes back into view or focus (at most once a minute).

Key

You can only bind a role whose permissions you already hold. Binding a role that would grant a permission you lack is refused — the same escalation ceiling that governs creating and assigning roles. See Roles and permissions.

Privileged groups

Once a group carries a role that grants elevated (escalation-sensitive) permissions, changing that group's membership becomes a privilege grant in its own right. Adding a member is no longer a plain Manage-users action:

• Adding someone to a privileged group requires Manage roles plus the escalation ceiling — you must hold every permission the group would confer.
• Automated provisioning cannot add members to a privileged group. A SCIM push that tries to drop a user into a group an admin has bound an admin role to is refused, so an IdP administrator can never mint a Strata admin by editing group membership. Membership of a privileged group is managed by a Strata admin, by hand. See SCIM provisioning.
• An invitation that pre-assigns a privileged group does not auto-apply it when the invitee first signs in — the invitee arrives with no verified granting authority, so the elevated group is skipped fail-closed and an admin adds it afterward through the guarded path.

The last-admin guard reaches groups

Because a group can now confer admin, the last-admin guard counts effective admins — anyone whose direct role grants admin access or who belongs to a group with an admin-granting role bound. Strata refuses an action that would leave the organization with zero effective admins, including:

• unbinding the admin role from the group that is the org's only admin source,
• deleting a privileged group that is the org's only admin source,
• removing the last effective admin from such a group.

Each refusal returns Cannot remove the last admin — promote another user to admin first.

Deleting a role that is bound

A role that is still bound to any group cannot be deleted. The request returns Cannot delete role — it is still bound to N group(s). Unbind it from those groups first. Unbind it everywhere, then delete.

Model limits

A group can lower how much of a model each of its members may use. Open Organization → Groups, click into a group, click Settings, and find Model limits. The section is shown to admins with View usage & billing or Manage billing; adding, changing and removing limits needs Manage billing. It works the same on a group your identity provider manages.

A limit is a number of tokens on one model per month (per trial period during a free trial), and it applies to each member of the group separately — it is not a shared pot. It can only lower your organization's limit for that model:

• Add a model limit offers the models that are on for your organization, have an organization token limit (their allowance under Organization → Models) and don't have a limit in this group yet. Pick the Model, type the Tokens per month — 2,000,000, 2M and 500k all work — and click Add limit. A number above the organization's limit is refused: A group limit cannot be higher than your organization's limit for this model (N tokens). When no model has an organization token limit, the section says No model has an organization token limit yet. Set one in Organization › Models, then lower it here. When every such model already has a limit in this group, it says Every model with an organization limit already has a limit here.
• Each row says what applies: Organization limit: N, or Your organization limit of N is lower, so that applies. A limit on a model that has since been turned off, or no longer has an organization limit, starts with Not applied: and gives the reason.
• To change a limit, edit its number; it saves when you leave the field. To remove one, click the × at the end of its row, and the group's members go back to your organization's limit. Emptying the field does not remove it.

A member in several groups with a limit on the same model gets the lowest one. Their own use of that model counts against it, and it applies to their scheduled agents' runs too. When it is used up, the same thing happens as when your organization's allowance for that model runs out — the turn stops, or runs on a fallback model where the allowance falls back — and Strata tells the member it is their own limit, without naming the group or the number. A stopped turn reads You've reached your limit for <model>. Your limit for this model is used up and resets on the 1st (UTC). Ask an admin to raise it, or switch models. A turn that ran on the fallback reads Answered with <fallback>. You have used your <model> limit for this period (resets on the 1st (UTC)), so this turn ran on <fallback>. During a trial, both say when your trial period ends in place of on the 1st (UTC).

Note

Model limits apply only where your deployment enforces model allowances. Until it does, the section shows Not enforced — Model limits are switched off for this deployment. — and a limit you save there does not stop anyone.

When a model retires and your organization moves to its replacement (Move to the replacement when a model retires, under Organization settings → Models), a group's limit on it moves to the replacement; if the group already had a limit on the replacement, the lower one stays. Setting and removing a limit are recorded in the audit log as group.model_cap_set and group.model_cap_removed.

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. Two rules matter:

• 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.
• Do not bind roles to a group your IdP provisions. Once a group grants elevated permissions, Strata stops accepting membership changes to it over SCIM — a privileged group's membership must be managed by an admin in Strata (above). Keep the roles that carry access on groups you manage by hand, and leave IdP-synced groups as plain labels.

Two places groups deliberately do not appear

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, a role being bound (group.role_bound) or unbound (group.role_unbound) — 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; membership in a group does not narrow which sources a member can search. If you need to restrict Knowledge Base search, control the SharePoint extension on the relevant role instead.

Related

• Managing users — roles, per-user limits and overrides
• Roles and permissions — what a role grants, and the escalation ceiling
• Organization settings → Models — the organization limits a group's model limits can lower
• Announcements — addressing a group
• SCIM provisioning — IdP-managed groups