Access control in SCHMA protects content integrity, database connections, and API configurations. To keep governance predictable, SCHMA provides distinct built-in membership roles with strict authority boundaries, alongside content-type access scoping for editorial staff.

Built-in workspace roles: Owner, Admin, Editor, and Reviewer

Every collaborator in a SCHMA workspace holds one of three canonical membership roles. Each role maps directly to specific operational responsibilities across the Studio and backend APIs:

• Workspace Owner: The root account authority. The Owner controls billing, Stripe subscriptions, database connection endpoints, workspace renaming and deletion, and role elevations/demotions. Only the Owner can transfer ownership or demote administrators.
• Administrator (Admin): Manages team operations, API keys, content models, webhooks, and publishing workflows. Admins can invite new editors and administrators, create and modify content type schemas, and manage delivery keys, but cannot modify billing or delete the workspace.
• Editor: Focuses exclusively on content creation and curation. Editors can write drafts, run AI generation prompts, manage version history, upload media assets, and publish entries. Editors cannot modify content schemas, view database credentials, create API keys, or manage workspace members.
• Reviewer: Dedicated read-and-comment collaborator. Reviewers can view content models and entries, and submit comments on drafts. Reviewers cannot edit fields, create or delete entries, publish or schedule content, restore versions, manage workspace settings, or resolve comments.

Role capability and authority matrix

The following matrix summarizes the verified permission boundaries across the three built-in roles:

Scoping Editor access with content-type permissions

While Editors have broad content editing capabilities by default, SCHMA supports granular content-type scoping (allowedContentTypes). This enables Owners and Admins to restrict specific editors to designated content models while preventing accidental edits to sensitive models.

• Unrestricted (Default): The editor can create, edit, and publish entries across all content types in the workspace.
• Scoped Restriction: The editor's permissions are locked to an explicit whitelist of content types (for example, blog-post and changelog). When scoped, all other content types (such as legal-pages or site-settings) are hidden from their Studio sidebar and blocked at the API level.

To configure content-type scoping, navigate to Settings > Team, click the action menu next to an Editor member, select Edit Access, and choose the specific content models the editor is permitted to manage.

Custom roles and granular permissions

Custom roles allow teams to tailor permissions to precise operational workflows—such as creating an agency translator role with read and write permissions but no publish rights, or a compliance auditor with read-only schema and content access.

Best practices for role assignment and security

Adhere to the principle of least privilege when configuring workspace collaboration:

• Reserve Owner for billing and security officers: Because the Owner holds unrestricted authority over database credentials and workspace deletion, limit the Owner role to one or two primary organizational accounts.
• Use Admin for technical leads: Grant Admin only to engineers and content architects who actively configure content schemas, API keys, and webhooks.
• Scope external collaborators: When inviting agency partners or freelance writers, assign the Editor role and scope their access to the exact content types relevant to their contract.