Roles & Permissions

Best when you have more than one person in a workspace and not everyone should touch billing, security, or the catalog. A role decides what a member can see and do; a custom role lets you narrow a built-in role to match how your team actually splits work.

Manage everything here from Workspace Admin → Roles (open the workspace menu at the bottom of the sidebar). Role administration is owner-only — admins can view the roles surface but not change it.

The six built-in roles

Every member holds exactly one built-in role. They're ordered least- to most-privileged, and each higher role includes everything the role below it can read.

Role	What it can do
Viewer	Read-only across the workspace — products, pricing, customers, invoices, analytics, reports. No changes, no data exports, no customer PII, no community posts.
Member	Everything a Viewer sees, plus post in the community, open support tickets, and read your storefront configuration. Still no configuration changes.
Developer	Reads on catalog + billing, plus full control of API keys, webhooks, integrations, agents/apps, and storefront-technical content (docs, changelog, pages). No billing changes.
Billing Admin	The full commercial lifecycle — create, edit, and delete rate cards, offerings, quotes, payment gateways; run and cancel bill runs; manage invoices; read customer PII.
Admin	Everything except closing the workspace, the hard security levers (MFA policy, IP allowlist, force-revoking sessions), and role administration.
Owner	Full control, including custom roles, security settings, and closing the workspace.

ℹ

Least privilege by default. A member never sees less than a viewer, and grants are explicit — adding a new capability to Aforo grants it to no role until it's deliberately assigned. Start people on the narrowest role that lets them do their job and widen only when they hit a wall.

Custom roles

A built-in role is a starting point. A custom role inherits one built-in role and adjusts it two ways:

Grant — add specific permissions on top of the inherited role.
Deny — remove specific permissions the inherited role would otherwise have.

Use them to model real job splits: a "Junior Billing" role that's Billing Admin without the ability to delete offerings, or an "Auditor" role that's a Viewer with audit-log access.

Two rules keep custom roles safe:

Narrow-only. You can't grant a permission the inherited role doesn't already hold. A custom role can never give someone more than the role it's built on — so you can't accidentally invent access you weren't given.
Deny wins. When a role both inherits a permission and denies it, the deny wins. A "Junior Billing" role that denies delete offering blocks that action even though the base Billing Admin role allows it.

Create a custom role

Workspace Admin → Roles → New role.
Give it a name and pick the base role it inherits (one of the six above — the base role is fixed once created).
In the permission picker, toggle the permissions to grant or deny, grouped by area (billing, catalog, integrations, storefront, …).
Save. Aforo validates the role and rejects it with a specific message if the name is taken, a permission is unknown, the same permission is both granted and denied, or a grant would widen beyond the base role.

Start from a template

Three templates seed the common patterns — pick one under New role → From template and adjust:

Template	Base role	What it changes
Sales Approver	Admin	Denies SSO configuration and removing org members — a deal-desk role that can't touch security or the roster.
Read-only Auditor	Viewer	Adds audit-log, reports, and event-log reads — read-everything plus the compliance trail.
API Developer	Developer	Adds webhook and integration management — an engineering role focused on wiring Aforo into your stack.

Assign a role

Assign built-in roles from Workspace Admin → Members (invite or re-role a member). Assign a custom role to a member from the Roles tab. Assignments take effect on the member's next request; removing an assignment reverts them to their built-in role.

How enforcement works

Permissions are checked on the server, not just hidden in the UI. The console hides actions a role can't perform as a convenience, but a hand-crafted request to a blocked action is rejected the same way — the role is the control, not the button.

Roles are scoped to a single workspace. A member's role in one workspace says nothing about their access in another; the parent organization has its own separate roles under Governance → Organization.

Two adjacent Workspace Admin tabs round out access control:

Session Policies (owner-only) — set per-role limits on session idle time, maximum session lifetime, and how many concurrent sessions a role may hold.
Access Reviews (owner-only) — on a monthly or quarterly cadence, the owner receives a review of who holds access (owners, role changes in the last 90 days, dormant API keys) and attests it. Overdue reviews escalate, so periodic access certification isn't something you have to remember to run.

Troubleshooting

Symptom	Cause	Fix
A member can't perform an action you expected	Their role (or a custom-role deny) doesn't include that permission	Check the member's role in Members, and any custom role in Roles. Widen the role or lift the deny.
"New role" rejects your custom role	The name is taken, a permission is unknown, a permission is both granted and denied, or a grant exceeds the base role	The error names the exact problem — fix that field and retry.
The Roles tab is read-only for you	Role administration is owner-only	An admin can view roles but not change them; ask a workspace owner to make the change.
A member still has access after you changed their role	The change applies on their next request	Have them refresh; active sessions can be ended from Active Sessions.
You want to give someone more than their base role allows	Custom roles are narrow-only by design	Assign a higher built-in role (or a custom role built on a higher base) instead of trying to widen a lower one.