Roles and Permissions

A member's role in a workspace decides what they can do there. Three roles cover almost every case.

The three built-in roles

Role	Permissions
Owner	Full access to every resource plus workspace:* (manage the workspace, invite and remove members)
Editor	Full CRUD on resources — no workspace management
Viewer	Read-only (:read) on the same resources

The line between Owner and Editor is workspace management, not resource access. An Editor can build, change, and delete anything inside the workspace; they just can't change who else is in it, rename it, or delete it.

Permission matrix

Resource families: chatflows, agentflows, assistants, tools, credentials, variables, apikeys, documentstores. Wildcards resolve (agentflows:* satisfies agentflows:create); a super-admin carries *; an unrecognised role falls back to Viewer.

In practice:

Action	Owner	Editor	Viewer
Open a flow on the canvas	Yes	Yes	Yes
Run a flow	Yes	Yes	No
Create, edit, delete a flow	Yes	Yes	No
Add or delete a credential	Yes	Yes	No
Create or revoke an API key	Yes	Yes	No
Upload documents, upsert a store	Yes	Yes	No
Read executions, messages, leads	Yes	Yes	Yes
Invite a member	Yes	No	No
Remove a member or change a role	Yes	No	No
Rename or delete the workspace	Yes	No	No

A Viewer can open a flow and read everything about it, but pressing send in the chat panel returns a permission error — running a flow spends credit, so it sits behind the same line as editing.

How permissions are resolved

Permissions are attached when you sign in and when you switch workspaces, based on your role in the active workspace. That's why switching reloads the app — your permissions changed with it.

Two consequences:

• A role change is enforced by the server immediately, but the member's interface keeps the permissions it loaded at sign-in. Until they sign out and back in — or switch workspaces — they may still see buttons that now fail.
• Your role in one workspace tells you nothing about another. The same person can be Owner here and Viewer there.

Choosing a role

Situation	Role
A colleague building flows with you	Editor
A client who wants to watch conversations and results	Viewer
A contractor on one project	Editor in a workspace holding only that project
Someone who needs to manage members and billing	Owner — transfer it deliberately

The most common mistake is giving Editor when Viewer would do. Editor is full delete rights on everything in the workspace; when someone only needs to read conversations and check performance, Viewer gives them exactly that.

The second most common is putting a contractor in a workspace with unrelated client credentials. Roles don't segment within a workspace — separate workspaces do.

note

Viewers can see that a credential exists but cannot read its secret. Nobody can: stored secrets are encrypted and never displayed again, even to Owners. See Credentials.

Related

• Inviting users — assigning a role
• Workspaces — the boundary roles apply within