> For the complete documentation index, see [llms.txt](https://docs.exavault.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.exavault.com/users-and-permissions/users.md).

# Users

Each person and automated workload that connects to ExaVault should have an individual user account. A user is either an administrator or a standard user. Use [Groups](/users-and-permissions/groups.md) when several users need the same folder permissions.

## Administrators and Standard Users

Administrators have full control of the ExaVault site. They can manage users and groups, configure site-wide settings, assign Home Directories, and grant folder permissions.

Standard users can work only within their Home Directory and the permissions granted to them. They cannot manage other users, groups, or site-wide settings.

## Create a User

Open *Users* and create a user with a unique username. Configure the user's display name, email address, Authentication method, Home Directory, expiration date, and folder permissions.

Use the Authentication method that owns the credential lifecycle:

* *Internal DB* stores and validates the user's password in ExaVault.
* *Active Directory & LDAP* validates the user's password against a configured directory. The ExaVault user must already exist unless Active Directory sync creates it.
* *SSO* sends web sign-in through the configured SAML identity provider. The ExaVault user must already exist unless SCIM provisions it.

An expiration date disables sign-in beginning on that date. Use it for temporary accounts when the end date is known.

## Disable Before Deleting

Disable a user when access must stop but you still need time to review the account. Open *Users*, select the user, and use *Enable/Disable*. A disabled user cannot sign in, but the account and its configuration remain available for review.

Before deleting the user, review:

* Share Links owned by the user;
* notification and other Automation rules owned by or targeting the user;
* group memberships and direct folder permissions;
* SSH keys and any external process that uses the account; and
* recent records in *Logging > Activity Search*.

Disabling a user also makes that user's Share Links unavailable. Re-enabling the user makes those Links available again if they have not otherwise expired, reached a download limit, or been deleted.

## Delete a User

Deleting a user is permanent account removal, not a temporary access control. Share Links owned by the user are deleted. Automation rules owned by the user are reassigned to another responsible account when possible, but rules that target the deleted user can become invalid and should be reviewed.

ExaVault prevents deletion of the last administrator while other users still exist. Keep at least two individually assigned administrator accounts so one administrator can recover access if the other is unavailable.

Deleting a user from a normal ExaVault installation does not imply the same file behavior as deleting a user from HyperPrivacy Mode. If the site uses HyperPrivacy Mode, read [User Deletions](/hyperprivacy-mode/user-deletions.md) before removing an account because that user's private file system is also deleted.

## Offboarding Checklist

1. Disable the user to stop new sign-ins.
2. Review Activity records and identify integrations that still use the account.
3. Transfer the work to a replacement user or dedicated workload account.
4. Reassign or recreate Share Links and review Automation rules.
5. Remove unnecessary direct permissions and group memberships.
6. Delete the user only after the dependencies and, for HyperPrivacy sites, the user's files have been handled.