Summary and recommendation
Sanity user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Sanity is a headless CMS with a project-scoped permission model.
Access is managed per project through sanity.io/manage → [Organization] → [Project] → Members, meaning every app or integration your team uses must be connected to the correct project with the correct role.
Built-in roles cover the majority of team needs: Administrator, Developer, Editor, and Viewer.
Custom roles with document-type and field-level granularity are available on Growth and Enterprise plans.
Quick facts
| Admin console path | sanity.io/manage → [Organization] → [Project] → Members |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full project access: manage members, billing, settings, datasets, tokens, and all content | All plans | Counts as a billable seat on paid plans | Only administrators can invite new members or change roles; there must always be at least one administrator on a project | |
| Editor | Create, read, update, and delete documents across all datasets; cannot manage project settings or members | Cannot manage members, billing, tokens, or project settings | All plans | Counts as a billable seat on paid plans | |
| Developer | Full content access plus ability to manage datasets and API tokens; cannot manage billing or members | Cannot manage billing or invite/remove members | All plans | Counts as a billable seat on paid plans | |
| Viewer | Read-only access to content in the Studio; cannot create, edit, or delete documents | Cannot create, edit, or delete content; cannot access project settings | All plans | Viewer seats do not count toward the billable seat allotment | Viewer role is useful for stakeholders who need read access without consuming a paid seat |
| Custom roles | Granular document-level and field-level permissions configurable per role | Growth or Enterprise (custom roles require a paid plan; exact tier confirmed on pricing page) | Counts as a billable seat | Custom roles use Sanity's access control language to define read/write/create/delete permissions at document type and field level |
Permission model
- Model type: hybrid
- Description: Sanity uses a combination of built-in roles (Administrator, Developer, Editor, Viewer) and optional custom roles. Custom roles allow granular, document-type-level and field-level permission rules defined via Sanity's access control configuration. Permissions are scoped per project.
- Custom roles: Yes
- Custom roles plan: Growth or Enterprise
- Granularity: Document-type level and field level; supports filter-based rules (e.g., restrict access to documents matching a specific condition)
How to add users
- Navigate to https://www.sanity.io/manage
- Select the target organization and project
- Click the 'Members' tab
- Click 'Invite members'
- Enter the invitee's email address
- Select the desired role from the dropdown
- Click 'Send invite'
- Invitee receives an email and must accept to gain access
Required fields: Email address, Role
Watch out for:
- Invitees must have or create a Sanity account to accept the invitation
- Invitations are per-project, not per-organization; users must be invited to each project separately
- Role assignment happens at invite time; it can be changed after the user accepts
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | No | Not documented |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Administrators can remove (revoke access for) a member from a project via the Members tab in Sanity Manage. Removing a member revokes their project access immediately. Sanity does not document a separate 'deactivate' state distinct from removal.
- Navigate to https://www.sanity.io/manage
- Select the target organization and project
- Click the 'Members' tab
- Locate the member to remove
- Click the options menu (⋯) next to the member
- Select 'Remove member'
- Confirm the removal
| Data impact | Behavior |
|---|---|
| Owned records | Content created by the removed user remains in the dataset; documents are not deleted when a member is removed |
| Shared content | All published and draft documents authored by the removed user persist in the project datasets |
| Integrations | Not documented |
| License freed | Removing a non-Viewer member frees a billable seat; Viewer seats are not counted toward the seat allotment |
Watch out for:
- Removing a member does not delete their content; all documents they created remain in the dataset
- If the removed user is the sole administrator, removal is blocked until another administrator is assigned
- There is no documented 'suspend' or 'deactivate' state; removal is the only way to revoke access
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Billable seat (Administrator, Developer, Editor, or custom role) | Full or role-scoped access to Studio and project management features | $15/user/month on Growth plan; custom pricing on Enterprise |
| Viewer seat | Read-only Studio access | Does not count toward seat allotment; included at no per-seat charge |
- Where to check usage: sanity.io/manage → [Organization] → [Project] → Members (shows current member count and roles)
- How to identify unused seats: No built-in last-login or activity report is documented in official sources; administrators must manually review the Members list to identify inactive users
- Billing notes: Growth plan includes up to 50 seats at $15/user/month. Viewer roles do not consume a seat. Enterprise pricing is custom. Overage billing applies for API and CDN request quotas exceeding plan limits, not for seats beyond the cap on Growth (seat limit is enforced, not overaged).
The cost of manual management
Sanity offers no native SCIM support, so every app in your IdP directory that maps to a Sanity project requires manual provisioning and deprovisioning. When an employee offboards, administrators must visit each project individually and remove the user from the Members tab - there is no bulk action or org-wide removal shortcut.
No built-in last-login or activity report exists, so identifying inactive seats means manually reviewing the Members list across every project. Viewer roles do not consume a paid seat, but all other roles (Administrator, Developer, Editor, custom) count against the Growth plan's 50-seat cap at $15/user/month.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Sanity's manual workflow is manageable for small, stable teams with a handful of projects, but every app your organization connects to Sanity adds another per-project provisioning obligation with no org-wide tooling to consolidate it.
Teams relying on SSO for offboarding should note that SAML role mapping handles provisioning attributes but does not remove users on IdP deactivation. If your organization requires automated deprovisioning or centralized access auditing, the Management API is the only programmatic path available.
Bottom line
Sanity's manual access management is straightforward for individual projects but does not scale gracefully across multi-project organizations. The absence of SCIM, bulk operations, and activity reporting means every provisioning and deprovisioning action requires deliberate administrator effort.
Teams with strict offboarding SLAs or frequent membership changes should plan for API-based automation or accept the overhead of per-project manual maintenance.
Automate Sanity workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
