Hide views and fields based on built-in group permissions (non-enterprise)

Yes, you can hide views and fields based on user roles in Sanity Studio, even on non-enterprise plans with the built-in roles! Here's how to do it with current Sanity Studio v3+ APIs:

Hiding Fields Based on User Role

You can use the hidden callback function in your schema fields to conditionally show/hide fields based on the current user's role. The callback receives a context object that includes currentUser:

{
  name: 'sensitiveField',
  type: 'string',
  hidden: ({currentUser}) => {
    const roles = currentUser?.roles.map(r => r.name)
    // Hide for non-admins
    return !roles?.includes('administrator')
  }
}

This is documented in the conditional fields documentation and works in Studio v3+.

Hiding Structure Views Based on Role

For customizing the Structure Builder based on roles, you can access currentUser from the StructureResolverContext that's passed as the second argument to your structure function:

// sanity.config.ts
import {defineConfig} from 'sanity'
import {structureTool} from 'sanity/structure'

export default defineConfig({
  plugins: [
    structureTool({
      structure: (S, context) => {
        const {currentUser} = context
        const isAdmin = currentUser?.roles.some(role => role.name === 'administrator')
        
        if (isAdmin) {
          return S.list()
            .title('Admin Structure')
            .items([
              // All document types
              ...S.documentTypeListItems()
            ])
        }
        
        return S.list()
          .title('Editor Structure')
          .items([
            // Limited document types
            S.documentTypeListItem('post'),
            S.documentTypeListItem('page')
          ])
      }
    })
  ]
})

The context object passed to your structure function includes currentUser, dataset, projectId, schema, and other useful properties as shown in the Structure Builder API reference.

Important Notes

• Users can have multiple roles - make sure your logic accounts for this by using .some() or similar array methods
• The currentUser object is available throughout Studio v3+ in context objects and hooks like useCurrentUser()
• For read-only fields (rather than hidden), you can use the readOnly callback with the same pattern
• Remember that hiding fields in the Studio is a UX convenience, not a security measure - actual access control for document-level permissions requires Custom Roles (Enterprise feature)

The key is that currentUser is available in many places throughout the modern Studio API, giving you flexibility to customize the Studio experience based on the built-in roles (administrator, editor, etc.) without needing enterprise custom roles!