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

# On-prem user management

> Disable, enable, delete and review users from the on-premises administrator account.

<Info>
  This page covers the **on-premises administrator** in a [self-hosted deployment](/deployment/models). Organisation admins manage their own members from [Manage members](/administration/manage_members).
</Info>

The **Users** page lists every account in the deployment. Go to **On-prem** in the navigation menu and select **Users**.

Each row shows the user's organisation, status (**Active** or **Disabled**) and three actions:

* **Activity**: what the user has created and done in Cymph, such as playbooks, assets, reviews and executions.
* **Membership**: the user's organisation and role, and the organisation workspaces they belong to, with their role in each. Workspaces of another organisation are marked **External**.
* **⋯**: **Enable** or **Disable User**, **Reset Password** and **Delete User**. Not shown on your own account.

## How to disable a user

Disabling suspends an account without deleting anything. Use it when someone leaves or should lose access for a while.

1. Go to the **Users** page
2. Click **⋯** on the user's row and select **Disable User**
3. Confirm by clicking **Disable user**

A disabled user:

* Is signed out of every session straight away and cannot use the API, including with API keys.
* Cannot sign in. After entering the correct password they see *"Your account has been disabled. Contact your administrator."* A wrong password gives the usual sign-in error, so the page never reveals that an account exists or is disabled.
* Receives no e-mails from Cymph.
* Keeps their organisation, role, workspaces and everything they created. Nothing is removed, and their licence seat stays in use.

Across Cymph, a disabled user:

* Is no longer offered when choosing people: RACI, reviewers, step assignees, workspace members, sharing and search. The API also refuses to newly add them to a RACI, a reviewer slot, an execution step or a workspace.
* Is shown as **Name (Disabled)** wherever they are already assigned. In the RACI matrix and on execution steps, a warning icon explains that they no longer have access.
* Is reported by [Risk Signals](/key-features/playbook-insights). On playbooks, a disabled Responsible or Accountable person makes the playbook *orphaned*. On executions, **Executions with steps assigned to disabled users** lists every open step that is waiting on them.
* Is skipped when a new execution starts: a step whose agent is disabled is assigned to the person running the execution instead.

## How to enable a user

1. Go to the **Users** page
2. Click **⋯** on the user's row and select **Enable User**
3. Confirm by clicking **Enable user**

The user can sign in again and finds everything as they left it.

## The last administrator of an organisation

An organisation with members must always keep an active administrator, so its last one is protected:

* **Disable User** and **Delete User** are unavailable for them, with a note explaining why.
* An administrator who is alone in their organisation can still be disabled or deleted.

To replace a manager without their help, first give another member the **Admin** role from the [organisation overview](/administration/organisation_management#how-to-change-a-members-organisation-role), then disable or delete them.

<Info>
  When the on-premises administrator is a member of an organisation, they count as one of its administrators. They hold every organisation permission.
</Info>

## How to delete a user

1. Go to the **Users** page
2. Click **⋯** on the user's row and select **Delete User**
3. Confirm the deletion

Only two things stop a deletion from this page: the user is an on-premises administrator, or they are the last administrator of an organisation that still has members. Open execution tasks do not block it; they are reported by the **Executions with steps assigned to deleted users** risk signal so they can be reassigned.

If the user is the last member of their organisation, the organisation is disbanded as well. The user is e-mailed a link to a backup of their data, including the organisation's when it is disbanded.

<Warning>
  Deleting a user cannot be undone. To keep the account but remove access, disable it instead.
</Warning>

<Info>
  Users deleting their own account are still stopped while they have open execution tasks, so their managers can reassign the work first. See [Delete account](/settings/delete_account).
</Info>