RBAC overview
Workspace roles vs account permissions, and how RankWatch enforces access.
RankWatch uses role-based access control (RBAC) at two scopes:
| Scope | Who it applies to | Managed in |
|---|---|---|
| Workspace | Day-to-day SEO operators on a team | Custom roles (permission keys like project.update) |
| Account | Billing, org profile, role CRUD | Organization owner only |
Workspace roles
Each team member has one workspace role (team_members.role_id). That role grants a set of permission keys checked on API routes and reflected in the product UI (hidden actions, disabled buttons, redirects).
Common workspace permissions include:
| Key | Product label |
|---|---|
project.read | View Projects |
project.create | Create Project |
project.update | Edit Project |
project.delete | Delete Project |
keyword.create | Create Keywords |
report.read | Read Reports |
See the dedicated pages for Edit Project and Create Project.
Account (owner-only) permissions
Permissions such as org.billing.read, rbac.role.manage, and notification.template.manage are never assignable to workspace roles. Only the organization owner can access account settings, even if a custom role name sounds administrative.
Enforcement
- API — every mutating route calls
requireTeamPermissionorisOrgOwneras appropriate. - UI — hooks like
usePermissions/useTeamPermissionsgate controls; missing permission shows an explanation or redirects.
Related product links
- Open Organization settings → Roles in the product app.
- Open Projects after signing in.