Users

The User directory is the built-in module for managing user accounts. It is reached from the people icon in the module bar.

A user is a row in directus_users. Each user has an email, a password (or an SSO identifier), a status, and a role. The role is what determines what the user can see and do — see Permissions for how access is configured.

The User directory

The User directory page lists every user the current viewer can see. It uses the same controls as a collection page: search, filter, sort, layout, and bulk actions. The navigation pane on the left groups users by role, so you can quickly jump to “all admins” or “all editors” without filtering.

A role with admin access sees every user. A non-admin role can only see users it has been granted read permission on (directus_users read).

Creating users

There are two paths for adding users.

Invite

Use Invite when you want a person to set their own password. The invitee gets an email with a link to a CairnCMS-hosted page where they choose a password and complete their account.

1. Open the User directory.
2. Click the invite button (person-with-plus icon) in the page header.
3. Enter one or more email addresses, separated by commas or new lines.
4. Choose the role to assign to the invited users.
5. Click Invite.

The invitee receives an email with a link to set their password. Until they accept, their user record exists with the Invited status and cannot log in.

The invite URL must match an entry in USER_INVITE_URL_ALLOW_LIST. See Auth for that allow-list configuration.

Create directly

Use Create when you want to set the password yourself, or when you are scripting account provisioning through the app:

1. Open the User directory.
2. Click the create button in the page header.
3. Enter at least an email address. Other fields can be left for later.
4. Save.

The new user starts with the Draft status and no role until you set them. Draft users cannot log in.

You can also invite users from a role’s detail page under Settings > Roles & Permissions. The role detail page has its own invite button that pre-selects the role.

User profile fields

Every user has a profile page. Your own profile is reachable by clicking your avatar at the bottom of the module bar; other users’ profiles are reachable from the User directory if your role has read access to directus_users. The page is the same component in both cases, but what is shown and what is editable depends on your role’s permissions — an admin sees and can edit every field; a regular user viewing their own profile sees only the fields their role grants self-update on.

The default fields on a user record are:

• First Name / Last Name
• Email — must be unique
• Password — hashed with argon2 before storage; never returned by the API
• Avatar — an image file
• Location — free text
• Title — free text job title
• Description — free-form notes
• Tags — keywords for filtering and search

Custom fields can be added through Settings > Data Model > Directus Users the same way you add fields to any other collection. Built-in fields cannot be removed.

Preferences

Preferences are profile fields a user typically edits for themselves:

• Language — overrides the project default language for this user
• Theme — Light, Dark, or System (matches the OS preference)
• Two-Factor Authentication — backed by the tfa_secret field; configured by scanning a TOTP QR code from the user’s profile
• Email Notifications — whether the user receives notification emails

Whether a user can edit these themselves depends on the role’s update permissions on directus_users scoped to id = $CURRENT_USER. The standard preset applied when App Access is enabled grants self-update on language, theme, and tfa_secret, along with most general profile fields. Email Notifications is not in the default preset. Add it to the role’s permissions if you want users to manage their own notification setting.

Admin-only fields

The following fields can only be edited by admins (or by users with explicit update permission on those fields):

• Status — see User status below
• Role — which role this user is assigned to
• Token — a long-lived static API token for this user; see Auth for how it’s used
• Provider — the SSO provider that authenticated this user, if any. Editable by admins; forced read-only for non-admins on existing users.
• External Identifier — the user’s identifier on the SSO provider. Same editability rules as Provider.

Read-only sidebar info

The user detail sidebar exposes:

• User Key — the user’s UUID
• Last Page — the last app page the user visited
• Last Access — when the user last hit the app or API

User status

Status determines whether a user can authenticate.

• Draft — incomplete user; cannot log in
• Invited — pending invite acceptance; cannot log in until they set a password
• Active — the only status that allows login
• Suspended — temporarily disabled; cannot log in. This is what role-deleted users get set to automatically.
• Archived — soft-deleted; cannot log in

Only Active allows authentication. The others all block login but leave the user record (and any references to it) in place.

Archiving and deleting

Users can be archived (soft-delete) or deleted (permanent).

To archive a user, open their detail page and click the archive button in the header. This sets their status to Archived and prevents login. Archived users still appear in references — for example, as the owner of files or items they created.

To delete a user, select them on the User directory page and click the delete button. Confirm the dialog. This is permanent and cannot be undone. References to deleted users may break depending on the foreign-key constraints on those references.

For most cases prefer archiving. Reserve deletion for users that should leave no trace, such as test or duplicate accounts created in error.

Users without a role

When a role is deleted, every user assigned to that role is set to role = null and status = suspended automatically. Such users effectively have only Public-role permissions and cannot log in until you assign them a new role and reactivate them.

Users can also exist with role = null from the start, for example, an admin can clear the role on a user record manually. Same effect: Public-role permissions and login blocked unless their status is also active and the Public role allows app access (it does not by default).

Where to go next

• Permissions covers how roles control what users can do.
• Auth covers passwords, SSO, two-factor enforcement, and static tokens.