Roles and permissions

    DatoCMS offers a thorough roles and permissions system that allows you to precisely specify what actions every team member can perform (ie. "read-only permission on every content, except for articles which can be freely created/updated but not deleted nor published online").

    The access to content is managed separately and independently in each DatoCMS project: Jack can have full ownership of project A, but be just a proofreader in a project B.

    Every DatoCMS project is automatically populated with the following roles, but you are free to create as many roles as you want, and assign them both to collaborators and API tokens:

    • Admin: Can do everything, including work with records, create and update models, configure project settings and work with API keys.
    • Editor: Can work with records, does not have access to models, API keys or project settings.

    For each role you can specify what the user is allowed and not allowed to do.

    Content-level permissions

    These rules determine what records a user can read/change/destroy, on a per-model basis.

    • Action:

      1. Read
      2. Create/duplicate
      3. Edit
      4. Publish/unpublish
      5. Delete
      6. Edit creator
    • Model: it's possible to give full access (everything allowed) to the model meal, but give zero access (can't even read) to the model drink.

    • Creator: it's possible to enable opening only the content which the user has created themselves (on users with its same role), and deny opening content created by other users.

    The most important aspect is that everything which is not explicitly allowed is denied. Here's an example: if you've enabled editing records, but didn't enable reading them, then the user won't be able to open the records. Even though it might feel counter-intuitive, this way of handling access rights helps preventing unsolicited access: when you set up everything explicitly, there is no chance of accidentally giving someone access to something they shouldn't have.

    Project-wide permissions

    A different set of permssions is related to what we call admins. The idea is to have a set of toggles that allow you to have access to a set of functionalities that regards general access to services or administrative functionalities, in particular the ability to:

    • modify models, fields and navigation bar
    • modify project's languages, deployment, timezones and SSO settings
    • manage roles and invite/remove collaborators
    • manage webhooks
    • manage API Tokens
    • manage deployment environments
    • create shared filters

    These abilities can be added both on collaborator and/or API tokens, exactly like all the other permissions.


    Inside roles, you can specify content-level permissions on a per-environment level. When forking an environment, for each role DatoCMS duplicates the content-level permissions you had on the original environment to the copy:

    Roles also have access-level permissions to environments. You can allow Roles to access:

    • All environments (useful for developers)
    • Only the primary environment (useful for content editors)
    • Only the sandbox environments (useful for API tokens)

    Important: The access-level permissions take precedence over content-level permissions!

    An example

    To better exemplify, let’s consider a project that:

    • has only one environment (the primary one), and
    • has a Blog Editor role that:
      • Rule 1: only gives access to the primary environment, and
      • Rule 2: only allows to manage records of type article.

    If I fork the primary environment to a new one called foobar, the content-level permissions get duplicated (that is, Rule 2 its copied, so blog editors can only manage records of type article also inside the foobar environment)… but they will only be able to do so when the foobar environment gets promoted to primary since, as per Rule 1, they don’t have access to to sandbox environments.

    This allows to safely test and experiment changes to permissions on the roles without affecting the work of your collaborators on the primary environment, and without giving them privileges to edit sandbox environments.