Appearance
Workspaces, roles & access control
In FlowRunner the workspace is the tenant boundary: every project, secret, upload and audit record belongs to exactly one workspace, and who can touch it is decided by your role in that workspace. This page explains the four roles, what each one can do, and how the server enforces those rules on every request.
The workspace is the tenant
Each project stores a workspaceId. A user's access to a project is resolved through their membership in that project's workspace — never through the project directly. Because every list and lookup is filtered by workspaceId, two customers on the same installation cannot see or reach each other's projects. When you open your project list, the server first calls listMemberWorkspaceIds to find the workspaces you belong to, then queries only projects whose workspaceId is in that set.
NOTE
A small number of older projects created before workspaces existed have no workspaceId. For those, access falls back to the original single-owner model (the createdBy author is treated as the owner). This is a temporary migration bridge, not the permanent model — once migration completes the fallback is removed.
The four roles
Roles are strictly ranked: owner (3) > admin (2) > editor (1) > viewer (0). A check for a minimum role passes if your rank is at least the required rank, so an owner can do anything an admin can, and so on down the ladder.
| Capability | viewer | editor | admin | owner |
|---|---|---|---|---|
| Read flows, runs, submissions, history, domains | ✅ | ✅ | ✅ | ✅ |
| Edit & publish flows, schedules, restore versions | ✅ | ✅ | ✅ | |
| Add domains, transfer a project to another workspace | ✅ | ✅ | ✅ | |
| Invite / remove members, change roles | ✅ | ✅ | ||
| Manage workspace secrets | ✅ | ✅ | ||
| Read the audit log, delete a project, workspace settings | ✅ | ✅ | ||
| Delete the workspace | ✅ |
TIP
Transferring a project needs editor in both the source and the target workspace — you can't push a project into a workspace you don't already work in.
How enforcement works
There is no "trust the frontend" here. Every API route independently re-checks the caller on the server, in two steps: first the session is authenticated (see Authentication), then a role gate is called before any data is read or written.
requireProjectRole and requireWorkspaceRole are the only gate. They return 401 when there's no signed-in user, 404 when a project doesn't exist (so you can't probe for projects you can't see), and 403 when you're not a member or your rank is too low. Read routes ask for viewer, edit routes ask for editor, member and secret management ask for admin, and deleting the workspace asks for owner.
Last-owner protection
A workspace must always keep at least one owner. Before demoting or removing an owner, the server calls countOwners; if that owner is the last one, the request is rejected with Cannot demote the last owner / Cannot remove the last owner. This prevents anyone — including the owner themselves via "leave" — from orphaning a workspace with no one able to administer it.
The audit log
Security-relevant administrative actions are appended to a per-workspace audit log, readable only by admin and above. Recorded events include secret.set, secret.deleted, member.role_changed, member.removed, member.left, project.transferred and workspace.deleted, each stamped with the actor, target and time.
WARNING
Auditing is best-effort by design: a failed audit write never blocks the operation it records, so the log should be treated as a strong administrative trail, not a guaranteed-complete ledger. Routine flow edits and publishes are not audited today — only the workspace/membership/secret events listed above.