Roles and permissions

Every person in a workspace holds one role. For the three internal roles the role decides what they may change, not what they may see; the fourth, Viewer, is scoped and decides both. This page lists the four 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 four roles

Role	Shown as	In one line
`admin`	Admin	Full access, including team, billing and connector settings.
`controller`	Controller Approver	Approves invoices at every tier and manages coding rules.
`ap_specialist`	AP Specialist	Reviews and codes invoices, and decides approvals addressed to them.
`viewer`	Viewer	Outside approver. Sees only the buildings assigned to them, and decides only approvals addressed to them.

There are four, 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.

The Viewer is the exception to everything else on this page. The first three roles differ in what they may change and otherwise see the same workspace. A Viewer does not. It reads only the buildings an Admin has assigned to it, it cannot code or edit an invoice, and it cannot read the audit trail at all. A Viewer with no buildings assigned yet sees nothing, and is told to ask an administrator. Use it for an outside owner, a condo board volunteer or a third-party approver; do not use it for staff.

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	Viewer
Connect, disconnect, test or resync a ledger	Yes	No	No	No
Map vendors and accounts to the ledger	Yes	No	No	No
Add an intake mailbox	Yes	No	No	No
Change workspace settings	Yes	No	No	No
Add, edit or delete an approval tier	Yes	No	No	No
Set a property's approver, auto-approve threshold, default GL account or cost center	Yes	Yes	No	No
Edit anything else on a property (name, address, unit count, aliases, photo)	Yes	Yes	Yes	No
Create or edit a legal entity	Yes	Yes	Yes	No
Split or re-split an invoice, edit allocations	Yes	Yes	Yes	No
Save or delete an allocation template	Yes	Yes	Yes	No
Change the plan or open billing	Yes	No	No	No
Invite people, change roles, remove access	Yes	No	No	No
Create, edit or delete coding rules	Yes	Yes	No	No
Run or retry an export	Yes	Yes	No	No
Change the CSV column mapping	Yes	Yes	No	No
Start a reconciliation run	Yes	Yes	No	No
Import properties, units, vendors or entities	Yes	Yes	Yes	No
Review, correct and code invoices	Yes	Yes	Yes	No
Read the whole audit trail	Yes	Yes	Yes	No
Read anything else in the workspace	Yes	Yes	Yes	Only assigned buildings
See pending invitations	Yes	No	No	No

Three of those rows are worth reading twice, because they are controls over money that the product does not yet restrict: legal entities, the allocations on an invoice, and the saved templates behind them. Re-splitting an invoice that has already been signed returns it to review and voids the signatures collected so far, which is the safe behavior, but any of the three internal roles can trigger it. If that matters in your workspace, the control today is review rather than permission.

The row above them went the other way. A property's primary approver, backup approver, auto-approve threshold, default GL account and cost center decide who signs for a building and how its spend is coded, so they are now written only by an Admin or a Controller Approver. The rest of the building's record — name, address, unit count, aliases, photo — stays open to every internal role.

Bulk import sits with the three internal roles for the same reason: setting up master data is the AP specialist's job. One thing it deliberately cannot do is set a property's primary approver, backup approver, auto-approve threshold, default GL account or cost center. Those five fields are refused in an import and named back to you, whatever your role — they are changed on the building's own page, where the guard that protects them can see the change. See importing your data.

Among the three internal roles one read is gated, and only one: the list of pending invitations is Admin-only, because it belongs with inviting and removing people. Everything else is open to all three. An AP Specialist can see the member list, the rules, the connectors and the whole audit trail — every entry in it, for every invoice and every person, not only their own — 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.

A Viewer reads none of it. The audit trail is open to the first three roles and closed to a Viewer, along with the vendor list, the rules, the connectors, the exports and the reports. If you need somebody inside your company who cannot read the trail, the product does not have that today: Viewer is built for somebody outside it.

The approval tiers are edited in Settings → Approval policy, and they are Admin-only, 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. One honest caveat: tier edits are not yet written to the audit trail.

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.
Roles do not separate editing from approving. All three internal roles may review, correct and code invoices, and editing an invoice is not restricted among them at all, so on a single-approver tier the person who corrected the total can be the person who approves it. The setting below is the control that changes that. (A Viewer cannot edit an invoice at any point, so it can never be its preparer.)

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.

Separation of duties

Separation of duties is a workspace setting, and it is off until an admin turns it on in Settings → Approval policy, on the same tab as the tiers. Only an Admin can change it — writing any workspace setting is Admin-only, and a Controller Approver or an AP Specialist can read the switch but not move it. Leave it off and approval behaves exactly as described above.

With it on, a person who materially edited an invoice — the amount, subtotal, tax, currency, invoice date, due date, invoice number, the vendor, the property it is coded to, or its split — or who edited a printed line item, or who sent it for approval, may not record an approval decision on that invoice. Somebody else has to. There is no bypass and no exception for Admins, so a one-person workspace that turns it on cannot approve its own invoices at all; that is the control working rather than a fault, and turning it back off is one setting away.

Five details worth knowing before you turn it on:

It is decided per invoice, from the audit trail, at the moment an approval is recorded — not from a role or a column. It covers the whole life of the document, so somebody who edited a total, had the invoice rejected and re-sent it is still counted as its preparer.
Only a person counts. Extraction by the model and a rule sending an invoice for approval are recorded with the system as the actor, so neither ever locks a human out.
Immaterial edits do not count, and a printed line is never immaterial. Correcting the memo on the document leaves you free to approve. Correcting money, dates, the vendor, the invoice number, the property or the split does not — and neither does editing a printed line item, whatever you changed on it, including its description. There is nothing immaterial on a line: rewriting "Landscaping, $600" as "Landscaping, $6,000" changes what the workspace is about to pay.
Changing the GL account alone does not count. The material list covers the money, the dates, the identity of the bill, which building pays and which vendor is paid. Choosing a different expense account does not make you the preparer.
Rejecting is never blocked. Whoever prepared an invoice may always send it back for review with a comment.

It layers on top of the approval tiers rather than replacing them: a tier requiring two approvals still requires two distinct people, and with this setting on neither of them may be the preparer. Nothing about confidence, amount or risk changes who is blocked — the rule is the same on a $50 invoice and a $50,000 one.

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 workspace 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.