> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ainomos.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Users

> Invite people, give them rooms and organisation roles, and deactivate or delete accounts.

The **Users** page lists everyone in your organisation. From here you invite people, add them to rooms, give them organisation roles, and close accounts that are no longer needed. Open **Settings**, then **Users**.

Who can do this: platform admins. Everything on this page is for them only.

## Read the list

The list has three columns: **Name**, **Access** (the rooms a person owns or belongs to, and any cross-room reading role) and **Last seen**. Search by name or email above the list. Badges next to a name show what is special about a person:

| Badge | Meaning |
| - | - |
| **Platform admin** | Manages the organisation's settings and people. |
| **Maintainer** | Switches maintenance on and off. |
| **Disabled** | The account is deactivated and cannot sign in. |
| **Invited** | A setup link was sent and the person has not set a password yet. **Last seen** reads **Not signed in yet**. |
| **Delivery failed** | The setup email could not be sent. |
| **via SSO** | Ainomos knows this person from a sign-in through your identity provider. |

Click a person to open their sheet. Everything that concerns one person happens there.

## Invite someone

You can invite people only while your organisation signs in with Ainomos accounts. If it signs in through its own identity provider, **Invite user** is disabled and a note says **People are managed in your identity provider**. Add people there instead. They appear on this page after their first sign-in, and you give them rooms and roles here. See [identity and single sign-on](https://docs.ainomos.ch/admin/identity-and-sso.md).

**1. Open the invitation**

Choose **Invite user**.

**2. Fill in the form**

Enter the person's details and pick their rooms, as in the table below.

**3. Send it**

Choose **Send invitation**. The page confirms **Setup requested for** the address.

| Field | What it does |
| - | - |
| **Email** | Required. The address becomes the person's sign-in. One address can belong to one organisation only. |
| **First name**, **Last name** | How the person appears in Ainomos. |
| **Language of the invitation** | **Deutsch**, **English**, **Français** or **Italiano**. Also the language Ainomos starts in for them. |
| **Rooms** | Optional. Your organisation's top room is preselected. The person joins each room as a member. To give someone a responsibility, add it later in the room. |

### What the invited person receives

They get an email in the chosen language that names your organisation and the person who invited them, with a link to set up their account. They choose their own password; the email contains none. After that they land on your organisation's Ainomos address. The link is valid for a limited time.

The confirmation means the sign-in service accepted the request to send. It does not prove the email arrived. Invitations need working email delivery: if it is not set up, Ainomos says so and creates no account.

To send a new link, open the person and choose **Resend setup invitation**. The earlier link stops working.

## Add someone to rooms

In the person's sheet, **Rooms & roles** lists their rooms, each marked **Member** or **Owner**.

* To add rooms, pick them with **Choose rooms** under **Add to rooms**, then choose the button that names the count, for example **Add to 2 rooms**. The person joins them as a member.
* To remove a room, choose the bin icon next to it and confirm with **Remove**. The person loses access to that room, and any responsibility they held there ends.

Ainomos records every change as evidence in the room it concerns. A room's last owner cannot be removed. Owners, deciders and curators are named inside each room; see [roles and permissions](https://docs.ainomos.ch/admin/roles.md).

## Change someone's organisation role

The person's sheet offers these controls. Each one asks you to confirm and writes an evidence record.

| Control | What it changes |
| - | - |
| **Grant admin** / **Revoke admin** | Makes the person a platform admin or takes it away. The last active platform admin cannot be revoked. An auditor must lose the auditor role first. |
| **Grant maintainer** / **Revoke maintainer** | Lets the person switch maintenance on and off and keep access while the organisation is closed for maintenance. While it is closed, its last maintainer cannot be revoked. |
| **Cross-cutting roles** | Chips for **Architecture**, **Security**, **Business** and **Auditor**. Click a chip to grant or revoke. |

A role that comes from your identity provider is controlled there: remove the person from the mapped group. To see the result of all roles and responsibilities, choose **Show rights**.

## Deactivate an account

Choose **Deactivate** in the person's sheet and confirm. The person is signed out at once and cannot sign in again. Their rooms, roles and responsibilities stay as they are, so **Activate** brings everything back. The last active platform admin cannot be deactivated.

You can deactivate, reactivate and delete only accounts that sign in with Ainomos. People who sign in through your identity provider are deactivated there.

## Delete an inactive account

**1. Deactivate first**

Only a deactivated account offers **Delete account**.

**2. Hand over what they own**

Ainomos refuses while the person still holds a responsibility in a room, or still owns decisions, documents, knowledge or apps. Hand these to someone else first.

**3. Delete**

Choose **Delete account**, read the warning and choose **Delete inactive account**.

You cannot delete your own account, accounts that sign in through your identity provider, or service accounts.

### What happens to their content

Deleting removes the account and the person's access: their rooms, cross-cutting roles and directory entry. Their history stays. Evidence records still name them, and the decisions, documents and other records they worked on keep their attribution.

If the sign-in service cannot be reached during deletion, access is already revoked. Retry the deletion once the connection works again.

## Related

* [Roles and permissions](https://docs.ainomos.ch/admin/roles.md)
* [Rooms](https://docs.ainomos.ch/admin/rooms.md)
* [Identity and single sign-on](https://docs.ainomos.ch/admin/identity-and-sso.md)
* [User visibility](https://docs.ainomos.ch/privacy/visibility.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.