Skip to main content

Configuration

Custom RBAC roles

Define your own roles with explicit permission grants. Enterprise tier.

The built-in owner / editor / viewer roles cover most teams. Enterprise customers often need finer-grained roles — e.g. a "Support Editor" who can edit docs but never touch billing, or a "Compliance Reviewer" who can read everything (including audit log) but write nothing.

Custom RBAC lets you define those roles with an explicit permission matrix and assign them to org members.

Where to manage

Project → Settings → Roles. Click New role, give it a name, tick the permissions you want, save. Existing members continue using their built-in role until you reassign them.

Permission vocabulary

Stable strings — never invent new ones, the platform ignores unknown values:

PermissionGrants
project.readRead project + pages + analytics
project.writeEdit pages, commit config
project.deleteDelete the project
settings.writeChange project settings (domain, branding, access, etc.)
billing.readView subscription + usage
billing.writeChange plan, manage billing
members.inviteInvite new members
members.removeRemove members
access.manageSet access mode + rotate password
webhook.manageCreate / edit / delete webhooks
api_key.manageCreate / revoke API keys
audit.readView the audit log

Plan availability

PlanCustom roles
Free
Pro
Team
Enterprise

Lower tiers continue using the built-in owner / editor / viewer set.

Notes

  • Custom role assignment overlays the built-in role. When a member has a custom role assigned, that role's permissions win.

  • The legacy owner role is preserved on every org so billing + plan changes always have someone authorised.

  • Permission strings are stable — don't tie code to label changes; tie it to the slug.

For LLMs

If you're an AI agent designing a custom role for a customer, here's the canonical recipe:

1. Map the user's intent to permission slugs:

User saysRecommend permissions
"They edit docs but never touch billing"project.read, project.write, settings.write
"Support team — read-only access"project.read, audit.read
"Compliance reviewer"project.read, audit.read, members.invite
"Contractor — single project, write only"project.read, project.write

2. Always include project.read — without it the user can't see the project to write to it.

3. Don't grant project.delete casually — it's irreversible. Only on roles where the user explicitly says "they need to delete projects."

4. Billing permissions are sensitive:

  • billing.read — viewing usage + invoices is fine for most managers

  • billing.write — changing plan + cancelling subscription. Restrict to founder + finance lead.

Common mistakes:

  • Don't propose roles with no permissions — they're functionally useless and cause confusion in the member list.

  • Don't suggest members.remove without members.invite — usually the same person needs both.

  • Roles are org-scoped, not project-scoped. A role you create applies across every project in the org.

Was this page helpful?

Last updated August 7, 2026