Roles: who can do what
Four roles, enforced on the server and not just hidden in the interface — so a member genuinely cannot reach your API keys, whatever they type in the address bar.
In this article (4)
Every person in a workspace has one of four roles. They stack: viewer < member < admin < owner.
What each can do
| Viewer | Member | Admin | Owner | |
|---|---|---|---|---|
| See flows, runs, results, Library, usage | ✓ | ✓ | ✓ | ✓ |
| Build and edit workflows | ✓ | ✓ | ✓ | |
| Run flows, batches, schedules, triggers | ✓ | ✓ | ✓ | |
| Share a flow read-only | ✓ | ✓ | ✓ | |
| See and manage API keys and pools | ✓ | ✓ | ||
| Connect MCP servers, manage agents and skills | ✓ | ✓ | ||
| Workspace settings, incl. the daily spend limit | ✓ | ✓ | ||
| Invite people, change roles, remove members | ✓ | ✓ | ||
| Override model prices | ✓ | ✓ | ||
| Change or remove another owner | ✓ |
The important property
Every one of those restrictions is enforced on the server, not merely hidden in the interface. The sidebar does hide the areas you cannot use — but typing the address, calling the API directly, or reaching for a different door all get refused with a permission error. This has been verified from a real member's session against every admin write path.
So a member is a safe default for most of a team: they can do the whole job — build, run, batch, schedule, share — and they cannot see a key, change a ceiling, or invite anyone.
Where a role travels with you
- An API token acts as its creator, with that person's role. Revoking the token cuts access immediately.
- A schedule or trigger runs as the person who created it and stops if they leave the workspace.
- A share link is not a role. It is read-only, revocable, and carries no ability to run or edit anything.
Choosing
| Person | Role |
|---|---|
| A designer or copywriter who uses the flows | Member |
| A client or manager who only needs to look | Viewer |
| Whoever manages provider accounts and connections | Admin |
| You | Owner |