People & access
Adding somebody is two decisions: what role they hold in the organisation, and which workspaces they can reach. Get both right at invite time and you rarely revisit it.
Invite someone
Settings → Members → Invite. Enter their email and pick a role. The invitation sits as Pending until they accept, and you can cancel it from the same page while it's waiting.
Which role:
- Member — for almost everyone. They operate the workspaces they can reach: connections, policies, grants, agents, approvals. They cannot touch billing, membership, or workspace structure.
- Admin — for people who should be able to change the plan, invite others, create workspaces, and turn remote access on. That's a genuinely wide remit; give it to people accountable for the organisation, not to people who just need to get work done.
- Owner — you. Owners can delete the organisation and redefine what roles mean. A second owner is a real decision, not a convenience.
Widening someone's role later takes ten seconds and no explanation. Narrowing it after they've grown used to the access is a conversation. Invite as a member unless you already know otherwise.
Scope people to workspaces
Org membership is the base grant; workspace scoping optionally narrows a plain member to specific environments. It only ever removes access, never adds it — org role always wins.
The rules, in full:
| Who | Reaches |
|---|---|
| Owner or admin | Every workspace, always. They're never scoped, and can't be. |
| Member with no assignments | Every workspace. This is the default. |
| Member with assignments | Only the listed workspaces, at the level stored for each |
That second row is the one that surprises people. A new member reaches every workspace until you scope them. If your production workspace shouldn't be open to everyone you invite, assign explicitly rather than assuming.
To assign: switch to the workspace, then console sidebar → Workspace → Members, and add them. Assigning them to one workspace immediately restricts them to that one, because the moment any assignment exists the "reaches everything" default no longer applies.
Viewer vs member
Each workspace assignment carries a level:
- Member — operates the workspace, still subject to the organisation's capability matrix.
- Viewer — read-only inside that workspace. They can see the dashboard, the audit log, the grants and policies as they stand, and change nothing.
Viewer is the right tool for one person who needs visibility without the ability to act — an auditor, a stakeholder, someone new. Turning capabilities off in the role matrix is the blunter instrument, because it applies to every member in the organisation.
Change someone's role
Settings → Members, then change the role on their row. It takes effect on their next request; there's nothing to sign out of. Narrowing a role narrows it immediately, so if you're demoting someone as a precaution, that precaution lands right away.
Offboarding someone
When somebody leaves, do these in order. The first step is the one that actually cuts access; the rest is tidying up after it.
- Remove them from the organisation — Settings → Members → remove. Their access ends at once, across every workspace. Their Permaura account survives; it isn't yours to delete.
- Revoke the agents they connected. An agent is a separate identity from the person who wired it up. Removing the human does not revoke an agent that's still running on their laptop or in a hosted client. Go to Agents in each workspace they could reach and remove anything of theirs — removal revokes its sessions immediately and deletes grants that named only that agent.
- Rotate the credentials they could have used. They never saw a sealed value, but they may have held the original key from the vendor's side. Rotate anything they set up: open the connection and replace its credential.
- Revoke their approval device if they'd paired one — Workspace → Devices. Read the caution below first.
- Check the audit log for the period around their departure. Not out of suspicion, but because it's the only record that will still answer the question in six months.
Once any device is paired, the gateway stops accepting unsigned approvals — and revoking that device does not lift the requirement. If the leaver's phone was your only paired approver, pair a replacement before revoking theirs, or you'll lock the approval queue behind a device nobody has. See Approvals.
On a hosted gateway, ask them to confirm it. There a second device is held until a device already paired signs off the enrolment, so the replacement you pair while their phone is still trusted waits on their phone. Either walk them through approving it before they go, or revoke their device first and accept the gap: with nothing trusted, the replacement enrols on your re-authenticated account alone.
Handing over an organisation
There's no one-click transfer. To hand an organisation to someone else: make them an owner, have them confirm they can reach billing and the role matrix, then step down or remove yourself. Do it in that order — an organisation with no owner is not a state you want to discover.
You'll also need to do this before you can delete your own account: deletion is blocked while you own an organisation that has other members in it.
Members and workspaces are plan-limited
How many people and how many workspaces you get comes from your plan — Free is a single personal workspace, and unlimited members with role-based access arrive on Team. If Invite or Create workspace is offering you an upgrade rather than a form, that's the limit rather than a permission problem. See Plans.