Datocms User Management: Roles and Permissions | OpsBlu Docs

Datocms User Management: Roles and Permissions

Manage collaborators, roles, and API tokens in DatoCMS. Covers the role-based permission model, environment-level access, and token scope configuration.

DatoCMS uses a role-based permission system where each collaborator is assigned a role that defines granular access to content models, records, media, and project settings. Roles support per-model and per-locale restrictions, making DatoCMS one of the more flexible headless CMS platforms for access control.

Permission model overview

DatoCMS structures access through:

  • Organization -- Billing container that owns one or more projects
  • Projects -- Individual DatoCMS instances with their own content models, environments, and collaborators
  • Roles -- Define what a collaborator can do within a project. Each collaborator is assigned exactly one role.
  • Environments -- Sandbox environments (fork of primary) can have separate access rules

Permissions are deny-by-default. A role must explicitly grant access to each capability.

Built-in roles

  • Admin -- Full access to all project functionality: content models, records, media, settings, environments, roles, API tokens, and billing. Can invite and manage collaborators.
  • Editor -- Can create, edit, publish, unpublish, and delete records across all models. Can manage media uploads. Cannot modify content models, roles, settings, or API tokens.

These built-in roles cannot be modified. For more nuanced access, create custom roles.

Custom roles (Professional plan and above)

Custom roles allow granular permission configuration:

Content permissions (per-model):

  • Read, create, edit, publish, unpublish, delete records
  • Can be set independently for each content model
  • "All models" shortcut applies to current and future models
  • Can restrict to specific locales (e.g., "can only edit French content")

Media permissions:

  • Upload, edit, delete assets
  • Can be restricted to specific upload folders

Schema permissions:

  • Create, edit, delete models and fields
  • Manage model ordering and appearance

Settings permissions:

  • Manage environments (create, promote, delete sandbox environments)
  • Manage webhooks and build triggers
  • Manage API tokens
  • Manage roles and collaborators
  • Access project settings (locales, timezone, etc.)

Build and deployment:

  • Trigger builds manually
  • View build logs

Create custom roles under Settings > Roles in the project dashboard.

Managing collaborators

Inviting a collaborator:

  1. Go to Settings > Collaborators
  2. Click Invite new collaborator
  3. Enter the email address and select a role
  4. Click Send invitation -- the user receives an email to accept

Changing a collaborator's role:

  1. Go to Settings > Collaborators
  2. Click the collaborator's row
  3. Select a new role from the dropdown
  4. Save -- changes take effect immediately

Removing a collaborator:

  1. Go to Settings > Collaborators
  2. Click the remove icon next to the collaborator
  3. Confirm removal
  4. Review API tokens the collaborator may have created

API tokens

DatoCMS uses bearer tokens for API access, managed under Settings > API Tokens:

  • Read-only API token -- Pre-created token for the Content Delivery API (CDA). Used by frontend applications to fetch published content. Safe to expose in client-side code (it is public by design).
  • Full-access API token -- Pre-created token with full Content Management API (CMA) access. Used for programmatic content management, migrations, and CI/CD pipelines. Must be kept secret.
  • Custom API tokens -- Created with specific permissions per model and environment. Supports read, create, update, publish, destroy scopes independently.

Custom tokens can be restricted to:

  • Specific environments (primary only, sandbox only, or specific named environments)
  • Specific models (e.g., a token that can only read "Blog Post" records)
  • Specific actions per model (read, create, update, destroy, publish, unpublish)

Analytics and tracking permissions

DatoCMS is a headless CMS, so analytics tracking is implemented in your frontend:

  • Build triggers and webhooks -- DatoCMS can notify external services when content changes. Configure under Settings > Webhooks or Settings > Build triggers. Requires a role with "Manage webhooks" or "Manage build triggers" permission.
  • Content for tracking configuration -- If you model tracking scripts or analytics config as DatoCMS content (e.g., a "Site Settings" singleton model with a GTM ID field), editing requires the appropriate model-level permission.
  • API access for analytics pipelines -- Use a read-only custom API token scoped to the specific models your analytics pipeline needs.
  • Audit log -- DatoCMS tracks content changes in the record activity log. View history on individual records to see who changed what and when.

Since DatoCMS has no frontend of its own, there is no built-in analytics dashboard. All tracking and reporting happens in the consuming application.

Environment-level access

On plans with sandbox environments:

  • Roles can be configured to allow or deny access to sandbox environments
  • The "Manage environments" permission controls who can create, fork, and promote environments
  • API tokens can be scoped to specific environments, preventing staging tokens from accessing production data
  • Promoting a sandbox to primary is a destructive action that requires explicit permission

Collaborator limits by plan

  • Free -- 1 user (project owner only)
  • Basic -- Up to 5 collaborators, built-in roles only
  • Professional -- Up to 15 collaborators, custom roles available
  • Enterprise -- Unlimited collaborators, custom roles, SSO support

Security features

  • SSO via SAML 2.0 is available on Enterprise plans
  • Two-factor authentication can be enabled per-user in account settings
  • No SCIM provisioning support -- user management is manual
  • Webhook signing secrets verify that incoming webhook payloads are authentic
  • API tokens can be rotated by deleting and recreating them

Sub-pages in this section

Back to top