Roles and permissions
Every person in a workspace holds one role. The role decides what they may change; it does not decide what they may see. This page lists the three roles, the capabilities attached to each, and the two rules that are enforced independently of any of it.
Read it before inviting your team, and again the first time somebody asks why a button is greyed out.
The three roles
| Role | Shown as | In one line |
|---|---|---|
admin | Admin | Full access, including team, billing and connector settings. |
controller | Controller Approver | Approves invoices and manages coding rules. |
ap_specialist | AP Specialist | Reviews and codes invoices. |
There are no other roles, no hierarchy between them, and no way to define your own. That is a considered limit rather than a gap in the roadmap: every restricted route in the product names the roles it accepts, so a custom role would be a role nothing has heard of. It would grant its holder nothing and read, entirely reasonably, as a bug.
Every plan has unlimited users. Approvers, property managers and your outside bookkeeper never appear on the bill, so there is no reason to share a login.
What each role may change
| Capability | Admin | Controller Approver | AP Specialist |
|---|---|---|---|
| Connect, disconnect, test or resync a ledger | Yes | No | No |
| Map vendors and accounts to the ledger | Yes | No | No |
| Add an intake mailbox | Yes | No | No |
| Change workspace settings | Yes | No | No |
| Add, edit or delete an approval tier | Yes | No | No |
| Change the plan or open billing | Yes | No | No |
| Invite people, change roles, remove access | Yes | No | No |
| Create, edit or delete coding rules | Yes | Yes | No |
| Run or retry an export | Yes | Yes | No |
| Change the CSV column mapping | Yes | Yes | No |
| Start a reconciliation run | Yes | Yes | No |
| Review, correct and code invoices | Yes | Yes | Yes |
| Read anything in the workspace | Yes | Yes | Yes |
Nothing gates a read. An AP specialist can see the member list, the rules, the connectors and the audit trail, and has a legitimate reason to: knowing who the controller is before sending an invoice for approval is part of the job, and the same names appear on every approval anyway.
The approval tiers are Admin-only, and narrowly so. Anyone who can edit the ladder can lower the required approver count to one and then approve alone, which means whoever holds the ladder holds the whole quorum. This was widened to controllers at one point and narrowed again deliberately; it is a control over money rather than a preference held by senior people.
Approval authority
Approval is not in the table above, because it is not decided by role alone.
- An invoice addressed to you can be approved by you, whatever your role.
- An invoice waiting on the queue with nobody named — the ordinary case, since sending for approval does not require naming a person — can be claimed by a Controller Approver or an Admin.
- Nobody can approve the same invoice twice. On a tier requiring two approvers, two signatures must come from two people.
The number of approvers required comes from the approval tier the invoice amount falls into, and it is enforced when each decision is recorded. Until the quorum is met, the invoice stays in the approval queue with a fresh unaddressed seat open for the next person.
Rejecting an invoice requires a comment and returns it to review. The comment is part of the audit trail, because "rejected" without a reason only moves the problem.
The rules that hold regardless of role
Two things are enforced below the level of roles, and no role can be configured out of them.
Tenant scoping. Every read and write is bound to the requesting organization at the query layer, rather than by filtering in the interface. A rule that assigns a reviewer by name searches members of that workspace only, so a rule saying "assign to Dana" cannot hand your invoice to a Dana who works somewhere else.
The last admin. A workspace must keep at least one Admin. Demoting or removing the last one is refused, whether you are doing it to yourself or to someone else. A workspace with no admin has no way back — nobody can invite, promote or reach billing — and recovering it is a support ticket rather than a click.
Self-demotion is otherwise allowed. Promoting a colleague and then stepping down is a normal handover, and the second admin is what makes it undoable.
Where the check actually happens
The server is the control. It re-reads your membership on every request, so somebody whose role changed a minute ago is refused before the browser has any idea.
The interface mirrors the same rules, and only for the sake of the message: you read "only an Admin can connect a ledger" on a disabled button instead of composing something for ten minutes and collecting a refusal at the end. Where the two ever disagree, the server wins.
Plan entitlements are a separate axis, and worth not confusing with roles. An Admin on the free plan is fully entitled by role and not at all by plan. See plans and limits.
Where to go next
- Inviting your team — sending the invitation and choosing the role.
- Approval tiers — how the quorum and the SLA are set.
- Audit trail — what is recorded against each person.
- Security and data — separation, retention, and what InletAP does not have.