CoursesUsers, roles and using rolesDefining roles

Users, roles and using roles

Lesson
4

Defining roles

Combine your resources with permission levels to define which roles can perform which actions
Log in to mark your progress for each Lesson and Task

When it comes to creating custom roles, it’s a case of combining your shiny new content resources with permission levels - basically defining the rules “this role has this level of access to this resource”.

When defining roles and resources, there are a couple of key decisions to be made:

  • Will your roles be wide ranging and attribute a number of permissions to a number of content resources?
  • Will your roles be very precise with users assigned multiple roles to cover their required access levels?

These types of decisions are subject to your specific use case, and for our Enterprise customers we’d recommend workshopping these with your Solution Architect.

Custom roles can have permissions applied to all datasets or to specific datasets. Often, adding permissions for all datasets will be perfectly acceptable – but if you have specific workflows or a more complex dataset configuration it can be useful to tailor permissions for each dataset.

An example is creating a custom developer role whereby developers can create content in a development dataset but not in a production dataset.

If you have a more complex project with many datasets – for example a multi-brand configuration where each brand has a number of datasets – then using dataset tags can be very helpful. You can tag each dataset with the brand it belongs to and grant access to all those tagged datasets in a single role definition. Don’t forget datasets can have multiple tags, too.

This means you can’t remove a permission given to a user in one role by removing it on another role.

As an example, if you were to assign the default Editor role to a user, this role includes the Publish permission for All documents in All datasets. If you were then to give this same user the Creator Team role from our first example above – which has Read only permissions for articles – they would still be able to publish the Article and Embargoed Article content resources as a result of the Editor role.

One thing to remember is that roles – including custom roles – can be applied to the API tokens that you generate, too.

This can be really helpful if you need to restrict the types of content that can be written to by middleware, or with particular cases where you might want to give third parties controlled access via the API.

If your organization has SAML SSO configured with Sanity to enable single sign-on – for example with Azure AD, Okta or another Identity Provider (IdP) – then you may benefit from role mapping to sync user roles in your IdP to user roles in Sanity.

Particularly for projects with many users, this can be a real time saver!

You might notice when applying permissions to roles via the user interface at sanity.io/manage you are restricted in the types of permissions you can create. These are baseline assumptions about the types of permission levels needed based on common practices. These allow:

  • No access - no access at all (except with public datasets which are publicly readable)
  • Read - read only
  • Update and Create - create, read and edit
  • Publish - create, read, edit, delete and publish/unpublish

What if you want to have a unique permission that grants the ability to delete but not create, or to create but not read? These are rare requirements, but in these cases specific permissions can be created via the Roles API rather than the UI.

Mark lesson as complete
You have 1 uncompleted task in this lesson
0 of 1