Directus User Management: Roles and Permissions | OpsBlu Docs

Directus User Management: Roles and Permissions

Manage users, roles, and granular permissions in Directus. Covers the CRUD+S permission model, custom roles, access tokens, and collection-level access...

Directus uses a granular role-based permission system where each role defines Create, Read, Update, Delete, and Share (CRUD+S) access per collection. Permissions can include field-level restrictions and record-level filters, making Directus one of the most flexible open-source platforms for access control.

Permission model overview

Directus structures access through:

  • Roles -- Named permission sets. Each user is assigned exactly one role.
  • Permissions -- CRUD+S rules applied per-collection within a role. Each action (create, read, update, delete, share) is independently configured.
  • Field-level restrictions -- Within a permission rule, specific fields can be included or excluded.
  • Item-level filters -- Permissions can include a filter rule (e.g., "can only read items where status = published" or "can only edit items where author = $CURRENT_USER").
  • Presets and validation -- Roles can define default values for new items and validation rules for specific fields.

Built-in roles

  • Administrator -- Full, unrestricted access to all collections, settings, and system configuration. Admin role cannot be modified or deleted. Members can manage users, roles, permissions, flows, and all platform settings.
  • Public -- A special role representing unauthenticated API access. By default, the Public role has no permissions. Any permissions granted here apply to requests made without an access token.

All other roles are custom-created.

Creating custom roles

Navigate to Settings > Roles & Permissions in the Directus Data Studio:

  1. Click the "+" button to create a new role
  2. Name the role (e.g., "Content Editor," "Marketing Manager," "Analytics Read-Only")
  3. Optionally enable App Access -- this controls whether role members can log into the Data Studio UI (without it, they can only use the API)
  4. Optionally enable Admin Access -- grants full unrestricted access (use sparingly)
  5. Configure per-collection permissions in the permissions grid

The permissions grid shows every collection as a row and CRUD+S actions as columns. For each cell, choose:

  • Full Access (green checkmark) -- Unrestricted access to all items and fields
  • Custom (orange dot) -- Opens the rule editor for field restrictions, item filters, and validation
  • No Access (red X) -- Action is denied entirely

Permission rule examples

Common custom permission patterns:

  • Author can only edit own posts -- On the "articles" collection, set Update permission with filter: { "author": { "_eq": "$CURRENT_USER" } }
  • Translator sees only content fields -- On any content collection, set Read permission with field restrictions to include only translatable fields
  • Marketing sees published content -- Set Read filter: { "status": { "_eq": "published" } }
  • Read-only dashboard user -- Grant Read on all collections, deny Create/Update/Delete/Share on everything

Managing users

Adding a user:

  1. Go to User Directory (the people icon in the sidebar)
  2. Click "+" to create a new user
  3. Enter first name, last name, email, and password (or enable email-based invitation)
  4. Select a Role from the dropdown
  5. Optionally set a Status (Active, Suspended, Invited)
  6. Save

Modifying a user:

  1. Go to User Directory and click the user
  2. Change their role, status, or profile details
  3. Save -- changes take effect immediately (no re-login required for permission changes)

Disabling/removing a user:

  1. Set the user's status to Suspended to preserve their account but block access
  2. Or delete the user entirely -- this may affect relational data if items reference the user

Access tokens and API authentication

Directus supports multiple authentication methods:

  • Static tokens -- Set per-user under their profile. The token is sent as a bearer token or query parameter. Useful for server-to-server integrations. The token inherits the user's role permissions.
  • Session tokens -- Generated via POST /auth/login with email/password. Returns an access token and refresh token. Tokens expire based on the ACCESS_TOKEN_TTL and REFRESH_TOKEN_TTL environment variables.
  • OAuth 2.0 / OpenID Connect -- Directus can authenticate users via external providers (Google, GitHub, Okta, etc.) configured in the project settings.
  • LDAP -- Directus supports LDAP authentication for enterprise directory integration.

Static tokens do not expire. When offboarding a user, either delete their account or clear their static token and suspend the account.

Analytics and tracking permissions

Directus is a headless data platform, so analytics implementation depends on how your frontend consumes data:

  • Flows (automation) -- Directus Flows can trigger on data events (item.create, item.update, etc.) and send data to analytics endpoints. Configure under Settings > Flows. Requires Administrator access.
  • Webhooks (via Flows) -- Push content change events to external analytics systems. Creating flows requires admin permissions.
  • Insights dashboard -- Directus includes a built-in Insights module for creating data visualizations and dashboards from your collections. Access to Insights is controlled by the role's App Access permission and read permissions on the underlying collections.
  • API for analytics queries -- Use a dedicated service user with read-only permissions on relevant collections. Create a static token for the integration.
  • Activity log -- Directus automatically logs all data mutations in the directus_activity collection. Administrators can view this under Settings > Activity Log.

Security features

  • SSO via OAuth 2.0, OpenID Connect, SAML, and LDAP -- configured in project environment variables or settings
  • MFA/2FA -- Supported via TOTP (Time-based One-Time Password) per user, enabled in user profile settings
  • IP allowlisting -- Can be configured at the reverse proxy level or via custom middleware
  • Activity logging -- All CRUD operations are logged with user, timestamp, IP, and user agent
  • Password policies -- Configurable via environment variables (PASSWORD_RESET_URL_ALLOW_LIST, custom password validators)
  • Role-based UI restrictions -- Roles without App Access can only use the API, reducing the attack surface for service accounts

Sub-pages in this section

शीर्ष पर वापस जाएँ