The account you sign up with is attached to an Admin role holding every permission in the product, because a workspace nobody can administer is worse than one that is over-permissioned on its first afternoon. Governance here is the work of carving that down — and the product is built so that the carving cannot strand a user, orphan a route, or lock the last administrator out of their own workspace.
We learned that from the provisioner. An earlier version created the tenant, the user, the default warehouse and the reference data in a single transaction, with the demo items seeded last — so anything that threw in the tail rolled the Admin role back with it. The workspace came up, the customer could sign in, and every administrative screen answered “System misconfiguration: No Admin role.” Signup now commits the tenant and the user first, and the grants run as their own stage that logs rather than throws.
The provisioner creates a role named Admin for the new tenant, grants it each of the 258 permissions in the catalogue, and attaches the signup user to it. Nothing else is created. There is no “Standard” and no “Approver” waiting for you — a starter role built on a guess about your org chart is a role somebody has to audit before they can trust it.
The role editor lists all 258 permissions under the 24 module headings below, with the whole group selectable at once. Most workspaces get to a workable model with three or four roles: someone who raises requests, someone who approves them, someone who touches money, and the person who set it all up.
A role is created against your tenant and resolved against your tenant. Permission lookups go through the user's roles for that tenant, so a person who belongs to two workspaces carries two independent permission sets and never the union of them.
A protected route runs the plan check first and the role check second. They are independent, they return different status codes, and they end in different places — because a person who has been told to do a job and cannot is owed an accurate reason. Blur the two and every plan limit arrives at your administrator's desk as a support ticket about broken permissions.
“This feature is not available on your current plan.”
Nothing to do with the person. The plan the workspace is on does not include the capability, so no role in the workspace can hold it — not even the Admin that holds all 258. On the web the user is returned to the page they came from with the upgrade prompt raised; over the API it is an HTTP 402 carrying plan_restricted: true and the permission name, so an integration can tell the two refusals apart without scraping a message.
One deliberate exception: delete_roles skips the plan gate entirely. A workspace that moves down a plan must still be able to tidy up the roles it built on the way up, and asking somebody to upgrade in order to delete something is a trap.
“You do not have the required permission to perform this action.”
The capability exists in the workspace and somebody has it — just not this person. The web response is a dedicated refusal page rather than a generic 403, and it names the permission that was missing, so the message your administrator receives is “I need approve_purchase_orders” rather than “it says I'm not allowed.” A user carrying no role at all is refused at the same gate with its own wording.
Over the API the same refusal is an HTTP 403 with code: permission.denied and the permission name in the body.
The order matters and is not arbitrary. Plan first means a downgraded workspace gives the same answer to every user rather than a confusing mix of upgrade prompts and access denials that depends on who happens to be logged in.
This table is generated from the same configuration the role editor reads, so it is the real catalogue rather than a marketing summary of it. Granularity follows risk: Inventory and Human Resources carry the most because they hold the most ways to move something irreversibly, while Dashboard carries one, because there is one thing to decide about it.
Permission names are the same strings in the role editor, in the route definitions, in the API refusal bodies and in the audit trail. There is no display layer translating approve_purchase_orders into something friendlier and losing the mapping on the way, which is what makes an access review possible to finish.
The obvious way to build role deletion is to delete the role. The users attached to it then hold no role, every permission check fails, and eleven people discover this at once on a Monday. The delete here is a four-step sequence and the destructive step is last.
If the role is one of the system defaults, the delete is refused outright with “System default roles cannot be deleted” and nothing further runs.
Before showing a confirmation, the screen asks the server what deleting this role would cost. If anyone holds it, the answer is a 422 carrying the number of affected users and the list of roles they could be moved to — so the dialog you see says “7 users” and offers destinations, rather than asking “are you sure?” about a number you do not know.
The delete is refused until you nominate a role to move those users into. The candidate list excludes the role being deleted and excludes protected roles, so “tidy up by sweeping everyone into Admin” is not one of the offered exits.
Every holder is moved to the nominated role first. Only then is the role removed, and the removal is recorded against your workspace with the role name and who did it.
Every one of these is a rule about a mistake that is easy to make in a role editor at four in the afternoon and expensive to undo. They are configuration rather than hard-coded, so a deployment can extend the list, but the shipped defaults are these.
These two are the workspace's anchors. Renaming Admin to something local — and the temptation is real — breaks the identity the provisioner and the impersonation path both look for by name.
Try to delete either and the role list refuses, before the user-count probe runs.
Not by another administrator, and not by itself. This is the lock that prevents the single most common self-inflicted lockout in a role system: an administrator tidying up their own role, unticking manage_roles, saving, and losing the ability to put it back.
Admin holds all 258 permissions permanently. Narrow access by moving people off it, not by narrowing it.
That name means something specific on the platform side, and a tenant-level role wearing it would read in a log line, an audit export or a support conversation as something it is not. The name is reserved and creation is refused, whatever the casing.
Refused on create and on rename, matched case-insensitively and trimmed.
This is the failure mode a role system actually dies of. Nobody removes a gate on purpose; a route gets copied, a middleware line does not come with it, and the application behaves identically for every honest user for as long as it takes somebody to notice. So the permission each route requires is declared in a map, and a test compares that map against the middleware the router really has.
The map has two halves because the two surfaces are gated separately, and an entry has to exist in the half it belongs to. The test fails in both directions — a route whose live middleware does not match its declaration, and a declaration pointing at a route that is no longer there. The second half matters more than it sounds: a stale entry is how a map stops describing the system while still passing.
The controller behind proof-of-payment files, vendor invoices and quotation attachments checks the tenant and deliberately nothing else — so the permission has to come from the route. Nine of those routes were tenant-only until August 2026, which meant any signed-in member of a workspace could pull them whatever their role. The signature routes beside them had gates; the attachment routes did not, and the module read as covered. They are gated and mapped now, and the test is what keeps them that way.
Both halves run in CI and fail the build. That is the honest version of “auditable access control”: not a claim that we are careful, but a check that runs whether or not we are.
There is a role audit screen in the workspace, paginated and scoped to your tenant. It is worth being exact about what lands in it, because “full audit trail” is the sort of phrase that survives a procurement questionnaire and then disappoints somebody in a review meeting.
The role name and the person who created it, timestamped.
The role name, the person, and the number of permissions the role holds afterwards.
The role name and the person, written after the holders have been reassigned.
The permissions entry records a count, not a diff. It will tell you that Grace changed the Warehouse Supervisor role and that it now holds 31 permissions; it will not tell you that the one she added was delete_adjustments. For a periodic access review that is usually enough to find the change worth asking about. For an evidence pack that has to show what changed, it is not, and a per-permission before-and-after is in the ledger below as something we can add.
Separately, the audit trail across the rest of the product is hash-sealed and verifiable, with no delete button anywhere in the interface. That is a different mechanism with a stronger guarantee, and it has its own page.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Anything in the middle column is a scoped piece of work on a system that already has the permission catalogue, the route map and the audit surface to hang it on. Tell us which row matters and we will come back with what it takes.
A hash-sealed trail with no delete button, and the two things that legitimately break a seal.
Session timeout, IP allowlisting, password policy and the security event log.
Which devices a workspace has seen, and what happens to one you no longer recognise.
SSO, magic links and where multi-factor sits in the ladder before a session exists.
The wider control story: policy, evidence and what a group of workspaces looks like.
Turning what the system recorded into something you can hand to an assessor.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
