Groups

A groupGroupNhómA set of people used to give roles and to name in sharing rules. A person can be in many groups; a group never holds money.Open in glossary gathers people for two jobs: it hands its members extra custom roles, and it can be named in a resource’s allow or deny list. It does nothing else — it never holds a budget and never counts as a department.

Key rules

1. Many per person. Anyone can be in any number of groups.
2. Groups add custom roles. Their capabilities merge with the person’s built-in role, their direct custom roles and every other group’s roles.
3. Groups can be named in sharing rules — in allow lists and in deny lists, where deny always wins.
4. Groups never hold money and are never department membership.
5. For departments, a group is only a bulk picker. It is expanded into people once; nothing stays linked.

What a group does — and doesn’t

A group does	A group never does
Bundle custom roles for its members	Hold a budget, quota or model list
Appear in a resource’s allow or deny rules	Count as a department or decide who pays
Let you pick many people at once when filling a department	Own a resource
Overlap freely with other groups	Grant a capability just by having members — only its roles do

Groups and departments look alike in a list of people. The side-by-side comparison is on Governance model › Departments and groups at a glance.

Roles through groups

RolesRoleVai tròA bundle of capabilities. Everyone has one built-in role — Org Owner, Org Admin or Org User — and groups can add custom roles on top.Open in glossary are the only source of capability. A person’s effective set merges three sources:

1. One built-in role from their organisation tier — Org Owner, Org Admin or Org User.
2. Custom roles held directly.
3. Custom roles from every group they belong to.

One resolver computes this set for every caller, with no cache across requests, so a change to a group’s roles applies on the next request. It keeps the provenance of each grant: a capability reached directly and through two groups shows all three paths when an administrator asks “why does this user have this?” (Effective permissions in the person’s profile).

Membership on its own grants nothing. A custom role that nobody holds and no group bundles grants nothing either. The five custom roles seeded with the organisation — Department Lead, Cost Analyst, Compliance Reviewer, Knowledge Curator and Agent Curator — are attached to no group until you attach one.

Which capabilities exist, and which can never go on a custom role: Roles and capabilities.

Groups in sharing rules

Every resource — agent, skill, prompt, application, artifact, knowledge base — carries its own visibility rules. Each rule is an effect (allow or deny) plus exactly one department, group or user. A rule matches a person when it names them, their department, or one of their groups.

• Allow a group to share a resource with everybody in it.
• Deny a group to take a resource away from everybody in it. Deny is checked first and wins over any allow, the org-wide switch and even ownership.

A contractor inside the Sales department is still denied a Sales agent when a deny rule names their Contractors group — see the worked example on Governance model. The full rule order is on Resource visibility.

Sharing with a group writes no per-person rows. A library row exists only where somebody departed from the default, so sharing with a group of two hundred writes nothing.

Groups and departments

A department’s membership is a direct list of users, never a group. When you fill a department, a group is only a bulk user picker:

The group is expanded once. No link to the group is stored, so adding or removing group members later moves nobody’s budget. Step by step: Manage departments.

Groups from your identity provider

Groups come from one of two sources, shown as Source on the Groups screen:

	Synced from your identity provider	Managed in the portal
Name, external id and membership	Owned by the provider, arrive over SCIM; read-only in the portal	Edited in the portal
Roles the group grants	Edited in the portal	Edited in the portal
Visibility rules naming the group	Edited in the portal	Edited in the portal

Nothing writes back to Keycloak or Entra ID: SCIM runs one way.

The organisation’s directory mode decides more:

• PORTAL mode — the portal owns who exists and their groups. You can create groups, add and remove members, and bulk-assign a department from a group.
• IDP mode — the provider owns the directory. Creating a group, adding or removing a member and bulk-assigning from a group are refused. What a group grants — its roles — and the visibility rules that name it stay editable.

In IDP mode a department is filled from provider groups instead of by hand. You attach a list of provider groups to a department (one Sales department is often Sales-VN + Sales-KH + a leads group), and one group can bill at most one department. A selection that would put a person in the groups of two active departments is refused. When membership changes upstream, people move automatically: the lowest department priority wins, an archived department receives nobody, and someone in no billed group falls back to General. If the provider deletes a billed group, the department keeps its name, budget, cost centre and history. Full rules: Departments › Directory mode and Departments from groups.

Why it works this way

Under the hood

Related