> For the complete documentation index, see [llms.txt](https://docs.artific.nl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.artific.nl/en/for-administrators/access/user-groups.md).

# User groups

Groups are how rights reach people. Found under **User management → User groups**.

## What a group is

A named set of people, carrying a set of roles. Everyone in the group gets everything those roles allow.

Groups are the only route from a role to a person. There is no way to give an individual a right directly, which is deliberate: it keeps access describable.

## Creating a group

**Add group** asks for a **Name** and a **Description**.

Name it after who is in it, not what it grants. *Support team* stays accurate when its rights change; *Can edit assistants* does not.

Write the description. In six months it is the only record of why the group exists and who belongs in it.

## The group screen

Selecting a group opens **Metadata**, where you change its name and description.

Some groups also have a **Roles** tab, which decides what the group grants. Attaching a role to a group is the moment rights are actually created. Everything else is bookkeeping.

{% hint style="info" %}
Role management is restricted. If a group has no **Roles** tab, or the roles column is missing from the list, you do not have rights to change role assignments. Your account manager can make the change or grant you the rights.
{% endhint %}

## System groups

Groups marked **System group** are managed by the platform. Their names and roles are fixed, but you can still add and remove members, which is the point: they are how your organisation is granted its standard rights.

## Adding people to a group

There are three ways, and the easiest depends on what you are doing:

| Situation                   | Where to do it                                                                                       |
| --------------------------- | ---------------------------------------------------------------------------------------------------- |
| One person, several groups  | The user's **User groups** tab. See [Users](/en/for-administrators/access/users.md).                 |
| Several people, one group   | Select them on the **Users** list, then **Select user groups**.                                      |
| Everyone new, automatically | **Default user groups** in [Organization settings](/en/for-administrators/organization/settings.md). |

## Groups from a parent organisation

If your organisation sits under a parent, some groups may come from above and apply here too. Those are managed by the parent organisation.

## Deleting a group

Deleting a group removes the access it granted from everyone in it, immediately.

{% hint style="warning" %}
Check who is in a group before deleting it. Nothing warns you that you are about to remove twenty people's access, and the effect is silent. They simply find screens missing.
{% endhint %}

## Designing a set of groups

Start with the smallest set that describes your organisation:

| Group            | For                                       | Typically carries                         |
| ---------------- | ----------------------------------------- | ----------------------------------------- |
| *Everyone*       | All staff                                 | Use assistants and the Toolbox            |
| *Builders*       | People who create assistants and elements | The above, plus creating and editing them |
| *Administrators* | The people who run the platform           | Organisation and user management          |
| *Support team*   | Whoever works the Inbox                   | The above plus Inbox access               |

Because rights add up, a builder needs only the *Builders* group if that role includes everyday use, or you can put them in both and keep each role focused. Either works; pick one convention and apply it consistently.

Add a group when a genuinely different kind of person appears. Resist adding one per project or per department if they would all carry identical roles.