Team and roles
A workspace is a data boundary, not a folder
A workspace holds scenarios and their versions, run history and logs, files, database collections, knowledge bases with their vectors, agent memory and variables, secrets, connections to external services, and chat history. None of it is visible from a neighbouring workspace — queries are scoped by workspace id at the storage layer, not filtered in the interface.
Hence the simple rule for laying workspaces out: create one where data must not mix — a separate client, a separate legal entity, a separate team with somebody else’s credentials. One workspace per scenario buys nothing: they land in different quotas, and each workspace keeps its own copy of secrets, documents and files.
A person’s access to a workspace is a membership row with a role. No row, no workspace: it does not appear in the switcher, and any request to it answers “not found” rather than “forbidden”.
Three roles
The role decides what a person may do inside one workspace. The same person can hold different roles in different workspaces.
- Viewer — reads. Sees scenarios and versions, run history with logs, files, collections, knowledge bases, chat history. Runs nothing, changes nothing.
- Editor — works. Everything a viewer does, plus editing and publishing scenarios, running them, chat, the assistant, uploading files and data.
- Admin — governs the workspace: members, secrets, connections, the widget, white-label, the Assistant MCP key, workspace spend.
| Action | viewer | editor | admin |
|---|---|---|---|
| See scenarios, versions, runs and logs | yes | yes | yes |
| Validate and auto-repair a graph | yes | yes | yes |
| Read chat history, files, collections, knowledge bases | yes | yes | yes |
| See the list of connections (secret fields masked) | yes | yes | yes |
| Create, edit and delete scenarios | no | yes | yes |
| Run scenarios, post to chat, cancel a run | no | yes | yes |
| Publish and unpublish | no | yes | yes |
| Upload files, edit collections and knowledge bases | no | yes | yes |
| Use the assistant in the editor | no | yes | yes |
| Delete chat history and node state | no | yes | yes |
| See secret names (values — nobody) | no | yes | yes |
| Create and change secrets and connections | no | no | yes |
| Rename the workspace, manage members | no | no | yes |
| Configure the widget, white-label, Assistant MCP key | no | no | yes |
| See this workspace's quark spend | no | no | yes |
| Erase recorded Telegram group history | no | no | yes |
Two rows deserve a second read. First: a viewer reads all of the data — chat history
with customers, uploaded files, the contents of collections. It is “look, don’t touch”, not
“see the shop sign only”. Second: a secret’s value is shown to nobody, ever, including
the admin who created it; only names are visible, because an editor needs them to write
{{ secret.NAME }} in templates.
The permission is checked by the server, on every request — a role cannot be bypassed by calling the API directly. (The Assistant MCP key is a separate door with its own permission set rather than a role: see API access.) The interface, however, currently hides only workspace settings and spend by role: edit and run buttons are still shown to a viewer and answer “forbidden” when pressed. A rough edge rather than a hole — but worth warning a colleague about in advance.
The owner is not a role but a separate entity
The owner is whoever created the workspace. They always count as an admin, but they differ from other admins in three ways:
- they cannot be removed from the workspace and cannot be demoted — both are refused;
- the bill is theirs: quarks for any run, whoever started it, are debited from the owner’s balance, and the owner’s plan decides the workspace’s limits (see Plan limits);
- they do not occupy a seat in the member quota. A plan “for N members” means N invited people plus the owner.
One operation belongs to the owner alone, and to no admin: the workspace’s quark budget. It is described below.
Adding a person
- Open Settings → Workspace.
- In the Add a member block enter the colleague’s email and pick a role.
- Press Add. The confirmation says which of two things happened — the person was added, or an invitation was mailed to them.
One form, two outcomes, and the difference is whether that address already has a Iterna account. If it does, the person becomes a member immediately and sees the workspace in the switcher on their next page load — no letter is involved and there is nothing to wait for. If it does not, an invitation goes out by email.
An invitation is a link that is good for 7 days. Opening it asks the person to sign in or to create an account, and joins them to the workspace as soon as they do — as the role you picked when you sent it. Until then it sits under Invitations in the same section, with the address, the role and the date it stops working; the button in that row revokes it, and a revoked link stops working at once.
A role is changed with the dropdown in the member’s row and applies immediately — there is nothing to confirm and save separately. Removing a member revokes access at once: their open tab stops working on its next request.
The workspace budget
The budget caps how many quarks this workspace may spend per billing period. Once it is used up, runs here stop while your other workspaces keep going — the money is shared, and what is being rationed is one line of work.
- Open Settings → Workspace.
- In the Workspace budget block, enter a number of quarks.
- Press Save.
A “spent so much of the budget” bar appears under the field. It counts the same counter the gate checks before a run, so it cannot show you a ceiling you will not actually hit. An empty field means no limit; to remove the budget, clear the field and save.
The block is visible to the owner only. A workspace admin changes everything else here — the name, the members, the integrations — but not the budget: the quarks being rationed are the owner’s, and nobody raises somebody else’s ceiling from the outside.
What goes into the journal
Sign-ins, member additions and removals, role changes and edits to secrets and connections are recorded with time, actor and IP address. The log exists for the argument about who changed a setting, and it is kept whether or not that person is still in the workspace.