---
title: Manage users and groups
description: "Users are the accounts that sign in to Auclio. Groups are how those accounts are referred to in permission rules. ## Understanding users and groups Every person who uses Auclio has a user account in the tenant. The account carries…"
url: "https://auclio.com/documentation/manage-users-and-groups/"
updated: "2026-08-24"
category: Permissions
---

# Manage users and groups

Users are the accounts that sign in to Auclio. Groups are how those accounts are referred to in permission rules.

## Understanding users and groups

Every person who uses Auclio has a user account in the tenant. The account carries their sign-in address, their name, and one or more *roles*.

Roles decide what a person can do with Auclio itself:

- **Admin** -- the tenant administrator. Can create and configure applications anywhere in the tenant.
- **User** -- can open the applications they have been given access to, and can view, create, and edit objects where permissions allow.
- **Readonly User** -- can open applications and view information, but cannot change data and cannot edit layouts.

Alongside these three there is one administrator role per application, listed under **Application roles** and named after the application it belongs to. It is a separate role from **Admin**: it grants administrator rights inside that one application, and nothing outside it. Someone can therefore administer one application while being an ordinary **User** everywhere else.

A user must always keep at least one role, and at least one of **Admin**, **User**, and **Readonly User**.

Roles are not the same thing as permissions. A role decides whether someone can build applications; a permission rule decides which applications, pages, and objects they can see. Most access is granted with permission rules, not with roles.

**Groups** are bundles of users. Permission rules can name a group instead of listing people individually, so that adding someone to the group grants them everything the group has. There are four kinds of group, described below.

Users and groups are managed in tenant settings, by a tenant administrator. Open the settings icon on the tenant homepage, then open **Users** or **Permissions**.

![Screenshot: Tenant settings with the Users tab open, showing the user list with the Source and Roles columns](/wp-content/uploads/2026/08/users-tab-scaled.png)
*Tenant settings with the Users tab open, showing the user list with the Source and Roles columns*

## Add a user

There are two ways a user account comes into existence, and which one applies depends on how your tenant is set up.

If your organization signs in with Auclio accounts, an administrator creates each account.

To add a user:

1. Open tenant settings.
2. Open **Users**.
3. Select **Create user**.
4. Enter the person's email address in **Username (e-mail)**.
5. Enter their **First name** and **Last name**.
6. Enter an initial **Password**.
7. Switch on **Require password change on first login**.
8. Select the roles the account should have in **Roles**. At least one is required.
9. Select **Create**.

The new account can sign in immediately. Requiring a password change means they set their own password the first time.

If your organization signs in through its own directory, accounts are not created here. They appear in Auclio automatically once the person has been given an Auclio role in your identity server. See [Work with federated users](#work-with-federated-users) below.

Your subscription sets a maximum number of users. When that limit is reached, **Create user** is disabled and the tooltip shows how many accounts are in use.

## Edit a user

To edit a user:

1. Open tenant settings.
2. Open **Users**.
3. Select the three-dot menu on the user's row.
4. Select **Edit user**.
5. Change the **First name** or **Last name**.
6. Select **Save**.

The username cannot be changed, because it identifies the account.

To change roles, use the role chips in the **Roles** column directly. Select the plus icon to add a role, and the cross on a chip to remove one. The menu groups the choices under **General roles** and **Application roles**.

A chip offers no cross when removing it would leave the account with no role at all, or with none of **Admin**, **User**, and **Readonly User**. That rule is applied by the interface rather than by the server, so it protects you from the mistake in Auclio but does not prevent the same change being made directly in your identity server.

To reset a password, select **Change password** on the same menu. You can set the new password as temporary, which forces the user to choose their own at the next sign-in.

## Remove a user's access

Auclio does not have a deactivate or disable command. There are two ways to end someone's access, and they differ in whether the account survives.

Remove their roles. A user with no Auclio role can no longer use Auclio, and their record is removed from Auclio at the next synchronization. Their account still exists in your identity server, so access can be restored by granting the role again. Use this when someone changes teams, or is away for a long period.

Delete the user. This removes the account entirely, and cannot be undone.

To delete a user:

1. Open tenant settings.
2. Open **Users**.
3. Select the three-dot menu on the user's row.
4. Select **Delete user**.
5. Confirm the deletion.

You cannot delete your own account, and you cannot delete a federated user from Auclio.

Deleting a user does not delete the objects they created. It does, however, remove them from any manual group and from any permission rule that named them individually, which is one reason to grant access to groups rather than to people.

## Synchronize users

Auclio keeps its user list in step with the identity server behind your tenant. The synchronization adds users who are missing, updates existing ones, and removes any who no longer have an Auclio role.

It runs automatically on a schedule. You can also run it yourself:

- **Sync users** on the toolbar reconciles the whole list. It runs in the background.
- **Sync user** on a row applies the same logic to one account immediately.

Run it manually when you have just changed someone's roles in the identity server and want the change reflected in Auclio straight away.

## Work with federated users

A federated user is an account that comes from your organization's own directory rather than from Auclio. The **Source** column shows where each account comes from -- **Local** for accounts created in Auclio, and the provider's name for federated ones.

Federated accounts are read-only in Auclio. Their names, passwords, and existence are owned by the directory, so **Edit user**, **Change password**, and **Delete user** are all disabled with an explanation.

What you can still do in Auclio is assign and remove roles, and add the user to groups.

To stop a federated user from using Auclio, remove their Auclio roles. Removing them from the directory removes them from Auclio at the next synchronization.

Auclio does not have a separate guest or external user type. Everyone who signs in is a user account, and what an external collaborator can see is controlled with permission rules rather than with a different kind of account.

## Understanding group types

Groups are managed in the **User groups** tab, inside **Permissions**. There are four types.

**Built-in** groups are created and maintained by Auclio. The one you will use most is **All users**, which contains every user in the tenant. Built-in groups cannot be edited or deleted.

**Manual** groups have an explicit list of members that you maintain. Use them for teams and roles that do not exist anywhere else, such as "Invoice approvers".

**Property-based** groups work out their members from the data. You name a dataset and a property, and whoever is named in that property becomes a member. Use them when membership follows the data, such as "the owner of each project". Property-based groups exist inside an application, because they depend on that application's datasets.

**Keycloak** groups take their members from groups in your identity server. Use them when your organization already maintains the right grouping in its directory, so that Auclio follows it rather than duplicating it.

Groups can be created for the whole tenant or for one application. A tenant-wide group is available in every application, and only a tenant administrator can create one. A group created inside an application is available there only.

## Create a group

To create a group:

1. Open tenant settings or application settings.
2. Open **Permissions**.
3. Open the **User groups** tab.
4. Select **Create user group**.
5. Choose the **Type**.
6. Enter a **Name** and a **Description**.
7. Complete the settings for the type you chose.
8. Select **Create**.

The type cannot be changed after the group has been created. **Built-in** is not offered, because built-in groups are created by Auclio. **Property-based** is offered only in application settings, because it needs a dataset to point at.

For a **Manual** group, add the members in the **Members** field.

For a **Property-based** group, select the **Dataset**, name the **Property** whose value identifies the members, and optionally list object identifiers in **Filter (object ids)** to limit the group to specific objects. Leaving the filter empty considers every object in the dataset.

For a **Keycloak** group, enter one or more group paths from your identity server in **Keycloak group paths**, pressing Enter after each one.

## Add users to a group

For a manual group:

1. Open **Permissions** and the **User groups** tab.
2. Select the three-dot menu on the group.
3. Select **Edit**.
4. Add the users in the **Members** field.
5. Select **Save**.

For property-based and Keycloak groups you do not add members directly. Membership follows the data or the directory, so change the property value, or the identity server group, instead.

Select **Members** on the group's menu to see who is currently in it. This opens the group with its **Members** tab in front. The list is calculated from the group's saved configuration, so save your changes before checking. A member who is named by the configuration but has no Auclio account yet is marked **Not created in Auclio**, and the group grants that person nothing until the account exists.

**Edit**, **Members**, and **Delete** are all unavailable for built-in groups, so the membership of **All users** cannot be listed from this menu.

## Remove users from a group

For a manual group, edit the group and remove the member chip, then save.

For a property-based group, change the value of the property that put them there.

For a Keycloak group, remove them from the corresponding group in your identity server.

Removing someone from a group removes every permission that group granted them. Check what the group is used for before emptying it.

## Delete a group

To delete a group:

1. Open **Permissions** and the **User groups** tab.
2. Select the three-dot menu on the group.
3. Select **Delete**.
4. Confirm the deletion.

Built-in groups cannot be deleted.

Deleting a group removes it from every access list that referenced it, which removes the access those lists granted. Check where a group is used before deleting it, and prefer emptying a group over deleting it if you may need it again.

## User and group recommendations

When managing users and groups:

- grant access to groups rather than to individual people, so that access survives staff changes;
- use the built-in **All users** group for things everybody should see;
- create a manual group per business role, not per person;
- use property-based groups where the data already records who is responsible;
- use identity server groups where your directory already maintains the grouping;
- give groups names that explain what they are for, not who is currently in them;
- give administrator roles sparingly, because administrators bypass permission checks;
- review the user list periodically and remove roles from people who have left.