Skip to main content
This page covers the on-premises administrator in a self-hosted deployment. Organisation admins manage their own members from Manage members.
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. 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, then disable or delete them.
When the on-premises administrator is a member of an organisation, they count as one of its administrators. They hold every organisation permission.

​
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.
Deleting a user cannot be undone. To keep the account but remove access, disable it instead.
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.