Roles and permissions — full reference
Authoritative role × permission matrix. 7 roles from super_admin to viewer. What each can and cannot do, per workspace area.
Written By Salvatore Sinigaglia
Last updated About 5 hours ago
Authoritative role × permission matrix. 7 roles from super_admin to viewer. What each can and cannot do, per workspace area.
Roles and permissions — full reference
Wevion has 7 roles with power levels in code, but permissions are enforced through explicit backend role groups and route guards. Do not infer that a higher numeric role automatically inherits every lower-role capability. Roles are assigned per workspace — the same user can be Owner in one workspace and Viewer in another. This article is the granular reference; for a 5-minute orientation see roles quickstart.
Who is this for
Admins setting permissions for the first time, owners restructuring access after a team grows, or anyone trying to figure out why they hit a "permission denied" error.
The 7 roles at a glance
These values are authoritative — sourced from apps/backend/src/utils/roles.ts (ROLE_LEVELS).
Full permission matrix
✅ = allowed, — = blocked, 👁 = read-only
Notes on a few gated actions:
- Connect / disconnect / reconnect ad platforms: allowed for mediabuyer (own connections) plus admin/owner/super_admin. manager is intentionally excluded (its scope spans other members, so it's not a self-service role).
- Invite / change roles / remove members: gated to owner/admin/super_admin (TEAM_WRITE). manager can read team data but cannot invite or change roles.
- Transfer ownership: strictly
requireRole('owner')— a super_admin cannot run it directly and must act via impersonation of the owner. - Impersonate user: allowed for owner and super_admin (not admin).
Treat any permission table as a practical guide rather than an exhaustive spec: access is enforced by role groups and per-route guards, not a strict cell-by-cell mapping, so a few edge actions may behave slightly differently. If a specific permission is business-critical, confirm it in the app for that role.
How permissions are enforced
Backend uses both numeric role levels and explicit ROLE_GROUPS in apps/backend/src/utils/roles.ts. Routes use onRequest: [app.requireRole(...)] decorators to gate access. Always verify the specific route guard before documenting a permission matrix entry. UI greys out buttons your role can't trigger and shows a tooltip explaining the reason.
Roles vs Teams (different concept)
Don't confuse roles with Teams. Roles set what a user CAN do across the workspace. Teams (team_membership in DB) are an optional grouping inside a workspace used for per-ad-account sharing. You can have a workspace without ever creating a Team — assign roles directly.
Special: super_admin
super_admin is set at Organization level, not workspace level. Visible to other super admins only. Bypasses all workspace-level RBAC checks (getAccessibleTeamIds returns all). Use sparingly — typically 1-2 super admins per Org (founder + CTO).
To grant: must already be super_admin. The first super_admin is set automatically on the user who creates the Organization.
Multi-workspace pattern
A common agency setup:
Each workspace membership consumes a seat on that workspace's Legal Entity — seats are counted per Legal Entity (one per workspace by default), not pooled across the whole Organization.
Customization
Custom roles are not supported — you use the 7 built-in roles. Enterprise SSO/SCIM (including group-based provisioning) is available on request as a dedicated configuration set up with Sales, but it doesn't add custom roles beyond the built-in set.
Common questions
- Can finance see ad performance? Yes, read-only where the relevant financial/reporting views are enabled. They cannot manage the subscription or payment methods unless billing route guards are changed.
- Can a viewer use Wavo? Yes — they can ask questions. They cannot trigger actions (Wavo refuses, suggests they ask an admin).
- Why does my admin see different things than another admin? Different workspaces. Roles are per-workspace.
- Can a member be in multiple Teams within a workspace? Yes — each Team has its own scope of ad accounts.
- What if a role's power level changes in a future release? Migration handled automatically; documented in release notes.
FAQ
How many roles does Wevion have?
Wevion has 7 built-in roles, ordered by power level: super_admin (100), admin (90), owner (80), manager (70), mediabuyer (60), finance (50), and viewer (40). Each unlocks a different set of capabilities across dashboards, campaigns, Creative Hub, the Rules Engine, integrations, team management, billing, and security, enforced by backend role groups and route guards.
Are Wevion roles set per workspace or globally?
Roles in Wevion are assigned per workspace, so the same user can be Owner in one workspace and Viewer in another. The only exception is super_admin, which is set at the Organization level and grants cross-workspace control. This is why two admins can see different things — they hold their admin role in different workspaces.
Can I create custom roles in Wevion?
No. Wevion does not support custom roles; you are limited to the 7 built-in roles from super_admin to viewer. Enterprise SSO/SCIM group provisioning is available on request via Sales, but it maps users to the built-in roles rather than adding new ones. For everyday needs, assign one of the built-in roles that matches the access each teammate requires.
Can a viewer use Wavo?
Yes. In Wevion, a viewer can ask Wavo, the AI assistant, questions, since viewing is read-only across the workspace. However, a viewer cannot trigger Wavo actions — Wavo refuses and suggests they ask an admin. Triggering Wavo actions requires mediabuyer, manager, admin, owner, or super_admin.
Who can transfer workspace ownership in Wevion?
Transferring workspace ownership in Wevion is strictly an owner-only action (requireRole('owner')) — a super_admin cannot run it directly and must act via impersonation of the owner. Managers, mediabuyers, finance, and viewers cannot transfer ownership. Canceling the subscription and deleting a workspace are also owner-only, while impersonating a user is allowed for owner and super_admin. Admins and owners share billing and API key management.