Headless CMS & Content Platforms
How do I implement role-based access control in Sanity for editors, reviewers, and admins?
7 min read
Role-based access control (RBAC) in Sanity starts with one idea: model your roles as clearly as you model your content. Once you define what editors, reviewers, and admins should (and shouldn’t) be able to do, you can encode those rules directly in your Sanity configuration so they’re enforced everywhere—from Sanity Studio to your APIs.
Quick Answer: You implement role-based access control in Sanity by defining roles and permissions (at the dataset/project level), then wiring those roles into your Studio configuration with tools like
structure, document-level permissions, and custom actions so editors, reviewers, and admins each see and can do exactly what they’re responsible for.
Quick Answer: Configure Sanity’s roles so editors can create and update drafts, reviewers can approve and publish, and admins can manage schemas, workflows, and project settings. Then reflect those roles in Sanity Studio using permission-aware structure and actions so the UI matches your content operations.
Frequently Asked Questions
How does role-based access control work in Sanity for editors, reviewers, and admins?
Short Answer: Sanity uses project roles and permissions to control who can read, create, update, and publish content. You then adapt Sanity Studio so editors, reviewers, and admins each see the workflows and actions that match their role.
Expanded Explanation:
Sanity is a content operating system, not just an editor UI. That means access control starts at the Content Lake (datasets, documents, mutations) and flows into Studio as configuration. You define roles at the project level—often mapping to “editor,” “reviewer,” and “admin”—and assign permissions like read, create, update, delete, and publish on specific datasets.
On top of that, you configure Sanity Studio (your editing environment) with code: desk structure, document actions, and custom tools can all be role-aware. Editors might only see their own sections and draft actions. Reviewers might get a queue of “Ready for review” content and access to publish. Admins keep full visibility, including schema changes, environment management, and automation. The result is RBAC that reflects how your team actually works, not a generic “one-size-fits-all” CMS roles setup.
Key Takeaways:
- Roles and permissions are defined at the project/dataset level and applied consistently via APIs and Studio.
- You customize Studio so editors, reviewers, and admins see the workflows and actions that match their responsibilities.
How do I set up basic roles for editors, reviewers, and admins in Sanity?
Short Answer: Create or map three core roles—Editor, Reviewer, Admin—with increasing permission levels, then assign users to those roles and configure Studio to mirror them.
Expanded Explanation:
Think of roles as the schema for your access model: you design them once and use them everywhere. A typical setup is:
- Editors: Can create and update drafts, but can’t publish or delete critical content.
- Reviewers: Can read everything, review and publish content, but don’t touch project-level configuration.
- Admins: Full control, including schemas, datasets, automation, and project settings.
You assign roles to users in the Sanity project (via the admin interface or CLI) and then use those roles in your Studio config. The Studio can hide or disable actions that a given role should never use, like “Delete” or “Publish.” Because schemas live in your Studio configuration, admins keep those in Git and control changes through code review and deployment.
Steps:
- Define role policies outside Sanity: write down what Editors, Reviewers, and Admins must be able to do and what they must not.
- Assign roles in your Sanity project: map users or SSO groups to Editor, Reviewer, and Admin roles at the dataset level.
- Mirror roles in Studio: use role-aware desk structure, document actions, and custom tools so each role’s day-to-day workflow is clear and constrained.
What’s the difference between roles at the project level and permissions configured in Sanity Studio?
Short Answer: Project roles enforce what’s possible (API-level permissions), while Studio configuration controls what’s visible and convenient (UI-level workflows and affordances).
Expanded Explanation:
Sanity separates the “hard” permission layer (who can mutate what in the Content Lake) from the “workflow” layer (how that work shows up in Studio). Both matter for RBAC:
- Project roles and dataset permissions define what a user can do regardless of UI: can they read documents in a dataset? Create new ones? Publish? Delete?
- Studio configuration (the code in
sanity.config.ts) defines how those permissions show up in practice: which lists they see, what actions appear for a document, which tools are available.
You might give an Editor role the ability to update documents but then hide the “Publish” and “Delete” actions in Studio. Even if a user tries to bypass the UI, the underlying role still prevents disallowed operations. Conversely, you can keep permissions broad for Admins but fine-tune the Studio to guide them into structured workflows like content releases, review queues, and localization dashboards.
Comparison Snapshot:
- Option A: Project roles/permissions: Hard security boundary; enforced on APIs, datasets, and mutations.
- Option B: Studio configuration: UX layer; controls visibility and workflow but not core security.
- Best for: Use project roles for guarantees, and Studio configuration for role-specific experiences and guardrails.
How can I implement a review workflow where editors draft, reviewers approve, and only admins manage configuration?
Short Answer: Use document status plus role-aware actions: editors create and update drafts, reviewers get actions to approve and publish, and admins own schema/config changes and any exceptional operations.
Expanded Explanation:
In Sanity, documents naturally move through states: draft, published, updated. You can implement a review workflow by combining these states with roles and custom actions. Editors work in drafts and can mark content as “Ready for review” (e.g., via a custom field or action). Reviewers get a queue of documents in that state plus access to publish actions. Admins do everything reviewers can do and additionally manage schema evolution, environments, and automation (Functions, Agent Actions, webhooks).
Because schemas live as code in your Studio configuration, admins can evolve workflows over time: adding a status field, connecting Agent Actions to populate review checklists, or wiring Functions to notify external systems when a reviewer publishes.
What You Need:
- A schema pattern that encodes review state (e.g., a
statusfield or tags likereadyForReview). - Role-aware actions and structure that expose “Draft,” “Ready for review,” and “Ready to publish” queues differently for editors, reviewers, and admins.
How do role-based access decisions impact overall content operations and governance in Sanity?
Short Answer: A clear RBAC model turns your Sanity project into a governed knowledge layer where content teams move faster without sacrificing control—content updates stay in the content team, while admins guard the system’s shape and integrity.
Expanded Explanation:
When your roles match your content operations, everything else becomes easier. Editors spend their time creating and refining content instead of fighting the tool. Reviewers focus on quality and risk, not chasing down drafts across channels. Admins can evolve schemas and automation knowing that change won’t unexpectedly widen access.
Sanity’s “schema as code” and content-as-data model means these decisions are versioned and inspectable. Roles and workflows are encoded in your configuration, not scattered across a tangle of custom APIs, dashboards, and spreadsheets. Event-driven automation (via Functions and Agent Actions) can safely run within this governed model—only triggering on mutations that a user is already allowed to make, and often producing reviewable changes instead of opaque transformations.
Why It Matters:
- Impact on velocity: Clear roles and Studio workflows let content teams own up to 90% of updates while devs focus on higher-value systems work.
- Impact on governance: A structured RBAC model plus schema-as-code gives you a repeatable way to audit who can change what, across brands, channels, and environments.
Quick Recap
Implementing role-based access control in Sanity for editors, reviewers, and admins is about aligning the permission layer (project roles, dataset access, mutation rights) with the workflow layer (Studio structure, actions, tools). Define your roles like you define schemas, assign them at the project level, and then configure Sanity Studio so each role has a clear, guided experience: editors work in drafts, reviewers control publishing, and admins govern schemas, environments, and automation. This structure gives you a governed knowledge layer that can power any application without relying on ad-hoc custom APIs or manual gatekeeping.