Access Control
A read-only map of what every role can do — system and custom roles, grouped by resource, with a side-by-side matrix and CSV export for audit evidence.
Access Control
When an auditor asks "who can void an invoice?" or you're about to hand someone a role, you want one screen that shows exactly what each role can reach — without clicking through a permission editor. Access Control is that screen: a read-only view of every role's permissions, grouped by resource, that you can compare side-by-side and export for evidence.
Open it from Governance → Access Control. It's available to workspace OWNER / ADMIN and organization ORG_OWNER / ORG_ADMIN.
This page is a viewer, not an editor. It has no create, assign, or revoke actions — it makes no writes at all. You define and assign roles in Workspace Admin → Roles; Access Control shows you the result.
Two views over the same data
- By Role — pick a role and read its grants, grouped by resource, with search and expandable groups. Best when you're answering "what can this role do?"
- Matrix — every role as a column, every resource group as a row. Click a column to expand it to individual permissions. Best when you're answering "which roles can touch invoices?" and want to compare.
What's in the grid
Rows are roles. The six system roles appear in a fixed order — OWNER, ADMIN, BILLING_ADMIN, DEVELOPER, MEMBER, VIEWER — followed by every custom role you've defined in this workspace.
Columns are resource groups — invoices, subscriptions, customers, API keys, SSO, exports, and so on. The groups aren't hardcoded: they're derived from the platform's permission catalog. Add a new permission or role on the backend and it shows up here automatically, so the matrix can't silently fall behind the code.
Each cell reads as one of four states: granted, partial (some permissions in the group, not all), denied, or unmapped.
How a custom role's grants are computed
Custom roles inherit from a system role, then layer their own changes. Access Control shows the effective result using the same precedence the platform enforces at request time:
- Start from the inherited system role's base grants.
- Add the custom role's explicit grants.
- Subtract its explicit denies — a deny always wins.
So a custom role built on ADMIN but with invoices:void denied shows granted across the Invoices group except that one permission, which reads denied.
Export for audit
Both views back a one-click CSV export (aforo-access-control-matrix-<date>.csv) that lists, per resource group, "granted / total (N denied)" for every role. It runs entirely in the browser — no backend export call — and is the artifact to attach to a SOC 2 access review.
Endpoints
Three read-only calls back the page:
What this page does not do
- No role creation, editing, assignment, or removal — that's Workspace Admin → Roles. Access Control only reads.
- No per-member view. It answers "what can this role do?", not "what can this person do?" To see an individual's access, check their role in Workspace Admin → Members and read that role here.
Related
- Roles & Permissions — define and assign custom roles.
- Organization — org-level roles that inherit into workspaces.
- Audit & Compliance — the audit-log side of access governance.