Team and roles
A workspace is a data boundary, not a folder
A workspace holds workflows 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 workflow buys nothing: they land in different quotas, and the platform cannot move objects between workspaces.
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 workflows 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 workflows, 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 workflows, 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 workflows | no | yes | yes |
| Run workflows, 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 credit 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: credits 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.
Two operations belong to the owner alone, and to no admin: archiving the workspace and its credit budget. Both are 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. They will see the workspace in the switcher on their next page load.
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.
Archiving instead of deleting
A workspace cannot be deleted; it is archived instead, and that is a deliberate replacement. Deleting would leave published workflows behind that keep answering in Telegram and in the widget while being invisible on every screen: the owner would pay for what they cannot see.
Archiving does four things:
- hides the workspace from every member — it leaves the switcher;
- unpublishes every workflow: the Telegram webhook is withdrawn on the Bot API side, the schedule stops, the public link and the webhook stop answering;
- keeps the data and the public tokens — restoring brings back the same addresses;
- frees a slot in the workspace quota, but does not free disk space: files, documents and vectors keep counting against the owner’s storage quotas.
Restoring does not republish the workflows — they come back as drafts, and the previous set of channels is recorded nowhere, so publishing has to be redone by hand. One more thing: the last live workspace cannot be archived, or the account would be left with none and the interface would have nothing to work with.
The workspace budget and the owner’s balance are different things
There is one wallet on the platform and it belongs to the account owner: the credits the plan includes, the remaining balance, and the charges from every workspace at once. A workspace budget is a self-imposed cap on top of that wallet: “the Support workspace gets no more than 2000 credits this period”.
| Owner’s balance | Workspace budget | |
|---|---|---|
| What it is | real money on the account | a spend cap for one workspace |
| Who sets it | the plan and purchases | the account owner |
| When exhausted | runs are refused everywhere | only this workspace’s runs are refused |
| When the counter resets | when a new period is granted | at the same moment |
The budget counts credits actually debited for this workspace during the period, and it is checked on both expensive surfaces: starting a workflow and talking to the assistant in the editor. Unset means no cap; zero also means no cap (a platform-wide convention: zero is “unlimited”, not “forbid everything”).
What goes into the journal
Sign-ins, member additions and removals, role changes, secret and connection edits, renames and archiving are recorded in a security audit log with time, actor and IP address. The honest caveat: that log is visible only to a global platform administrator in the system console — there is no “who did what in my workspace” screen for a workspace admin today.