Datocms Roles and Permissions Guide

Understanding DatoCMS roles and permissions is essential for secure and efficient project management. This guide explains each role, their capabilities, and best practices for access control.

DatoCMS Permission Model

DatoCMS uses a role-based access control (RBAC) system with predefined roles and customizable permissions per environment.

Key Concepts

Roles: Predefined sets of permissions for different user types Environments: Separate content spaces (primary, sandbox) API Tokens: Programmatic access with specific scopes Content Model: Schema defining content structure

Standard DatoCMS Roles

1. Owner

Access Level: Full control over everything

Capabilities:

• Manage all project settings
• Manage billing and subscription
• Invite and remove collaborators
• Assign roles to users
• Manage all environments
• Configure content model
• Create/edit/delete all content
• Manage API tokens and webhooks
• Configure roles and permissions
• Delete project

Use Cases:

• Project founders
• Business owners
• Senior leadership with full oversight

Security Requirements:

• Mandatory: SSO + MFA enforcement
• Regular security audits
• Documented approval for role assignment
• Quarterly access review

Best Practices:

• Limit to 1-2 people per project
• Never share credentials
• Use dedicated email (not personal)
• Enable all available security features

2. Admin

Access Level: Full access except billing and project deletion

Capabilities:

• Invite and remove collaborators
• Assign Editor/Translator roles (cannot assign Admin)
• Manage all environments
• Configure content model
• Create/edit/delete all content
• Manage API tokens
• Configure webhooks
• View activity logs

Cannot Do:

• Manage billing
• Delete project
• Assign Admin role to others
• Remove Owner

Use Cases:

• Content managers
• Technical leads
• Project managers

Security Requirements:

• SSO + MFA recommended
• Regular permission audits
• Document role assignments
• Monthly access review

Best Practices:

• Limit to 2-5 people per project
• Grant only when full access needed
• Review quarterly
• Document all Admin actions

3. Editor

Access Level: Full content management, limited settings

Capabilities:

• Create/edit/delete content in assigned environments
• Upload and manage assets
• Publish content
• Use all content types
• View and use content model
• Collaborate with other editors

Cannot Do:

• Modify content model
• Invite users
• Manage API tokens
• Access billing
• Configure webhooks
• Change project settings

Use Cases:

• Content creators
• Content managers
• Marketing team members
• Regular contributors

Security Requirements:

• MFA recommended
• Environment-specific access
• Content approval workflows (optional)

Best Practices:

• Most common role for team members
• Grant access only to needed environments
• Use for day-to-day content work
• Review access quarterly

4. SEO Editor

Access Level: Content editing with focus on SEO fields

Capabilities:

• Edit SEO metadata (title, description, OG tags)
• Edit content in assigned environments
• View content structure
• Upload images for SEO
• Manage meta tags

Cannot Do:

• Modify content model
• Delete content
• Invite users
• Access settings

Use Cases:

• SEO specialists
• Marketing coordinators
• Content optimizers

Best Practices:

• Use for SEO-focused team members
• Combine with Editor role if broader access needed
• Review SEO changes regularly

5. Translator

Access Level: Translation-focused content editing

Capabilities:

• Edit translated content fields
• View content in all locales
• Translate content
• Manage locale-specific content

Cannot Do:

• Edit content model
• Delete content
• Publish content (in some configurations)
• Access settings

Use Cases:

• Translation team
• Localization specialists
• Multilingual content managers

Best Practices:

• Grant access to specific locales only
• Use for multi-language projects
• Review translations before publication

6. Read-only / Viewer

Access Level: View-only access to content

Capabilities:

• View all content in assigned environments
• View content model
• View assets
• Export content (if enabled)

Cannot Do:

• Edit any content
• Create content
• Delete content
• Upload assets
• Change settings

Use Cases:

• Stakeholders needing visibility
• Auditors
• Clients reviewing content
• Temporary contractors
• External reviewers

Best Practices:

• Use for oversight without editing rights
• Time-box access for external users
• Review and remove when no longer needed
• Grant only to specific environments

Custom Roles

DatoCMS allows creating custom roles with granular permissions.

Creating Custom Roles

1. Navigate to Settings → Roles
2. Click Add role
3. Configure permissions:
   • Content permissions: CRUD on specific models
   • Asset permissions: Upload, edit, delete
   • Environment access: Which environments
   • Locale access: Which languages

Custom Role Examples

Content Approver:

• View all content: Yes
• Edit content: No
• Publish content: Yes
• Delete content: No

Asset Manager:

• View content: Yes
• Edit content: No
• Manage assets: Yes
• Upload assets: Yes

Draft Writer:

• Create content: Yes
• Edit own content: Yes
• Publish content: No
• Delete content: No

Environment-Based Permissions

Primary Environment

Typical Access:

• Owner: Full access
• Admin: Full access
• Editor: Limited to approved editors
• Others: Read-only or no access

Sandbox/Staging Environments

Typical Access:

• Developers: Full access for testing
• Editors: Limited access
• External: No access

Best Practices

• Restrict primary environment to trusted users
• Use sandbox for experimentation
• Test content model changes in sandbox first
• Promote changes to primary after review

API Token Permissions

Token Types

Full Access Token:

• Read and write all content
• Modify content model
• Manage assets

Read-only Token:

• Read content via GraphQL API
• No write permissions
• Safe for frontend applications

Environment-Scoped Token:

• Access limited to specific environment
• Useful for preview deployments

API Token Best Practices

1. Use read-only tokens for frontend applications
2. Scope to specific environment when possible
3. Rotate regularly (quarterly minimum)
4. Never commit to git - use environment variables
5. Revoke immediately when user leaves
6. Monitor usage via activity logs

Permission Matrix

*Admin cannot assign Admin role **Only in assigned locales

Role Selection Guidelines

Choose Owner for:

• Business owners
• Legal entity representatives
• 1-2 maximum per project

Choose Admin for:

• Technical leads
• Content operations managers
• 2-5 maximum per project

Choose Editor for:

• Content creators
• Marketing team
• Daily content contributors
• Most team members

Choose SEO Editor for:

• SEO specialists
• Marketing coordinators
• When full editor access not needed

Choose Translator for:

• Translation teams
• Localization specialists
• Multi-language projects only

Choose Read-only for:

• Stakeholders
• Auditors
• Temporary reviewers
• External clients

Access Control Best Practices

Principle of Least Privilege

Grant minimum access needed:

1. Start with Read-only
2. Upgrade to Editor if needed
3. Only grant Admin when absolutely necessary
4. Owner role extremely rare

Regular Access Reviews

Monthly:

• Review new users added
• Verify role appropriateness
• Check for inactive accounts

Quarterly:

• Full collaborator audit
• Environment access review
• API token review
• Role justification check

Annually:

• Complete access recertification
• Document all access
• Archive audit logs

Documentation Requirements

Document for each user:

• Date added
• Approver
• Role assigned
• Environment access
• Justification
• Review date
• Removal date (if applicable)

Security Incidents

If Account Compromised

1. Immediate Actions:

   • Remove user from project
   • Revoke all API tokens
   • Review recent activity logs
   • Check for unauthorized content/model changes
   • Verify no malicious webhooks added

2. Investigation:

   • Determine scope of compromise
   • Check if API keys exposed
   • Review content modifications
   • Verify no data exfiltration

3. Remediation:

   • Restore any damaged content
   • Rotate all shared credentials
   • Reset project API tokens
   • Notify affected team members

4. Prevention:

   • Implement stronger access controls
   • Mandatory MFA for all users
   • Regular security training
   • Quarterly access audits

Next Steps

• Adding and Removing Users - User lifecycle management
• DatoCMS Integrations - Configure tracking and tools

Related Resources

• DatoCMS Roles Documentation
• DatoCMS API Tokens
• DatoCMS Security