What is a workspace?
Sub-organisation containers that scope storage sharing and credentials - and act as a real read boundary.
A workspace is a container inside an organisation. Shared storage configurations attach to exactly one workspace, credentials bind to one workspace at issuance, and what you can see is determined by the workspace your session is bound to.
The hierarchy is two levels - organisation → workspace - and every organisation
has exactly one built-in default workspace (named Default). It cannot be
renamed or archived, and every organisation member can use it at their organisation
role. Until you create additional workspaces, Eddytor behaves as if workspaces
didn't exist.
Why workspaces
- Scoped sharing. A storage configuration shared into a workspace is visible to that workspace's members only. Sharing with the whole organisation is the special case of sharing into the default workspace.
- A read boundary, not a label. A session or API key bound to workspace A cannot list workspace B's shared configurations - including for organisation Admins. Admin rights mean you may bind to any workspace, not that you see all of them at once. To look elsewhere, you switch.
- Blast-radius control for keys. An API key reaches only the workspace it was minted in; archiving a workspace revokes its keys.
Access model
| Who | Access |
|---|---|
| Organisation Admin | Admin in every workspace, implicitly |
| Any org member, in the default workspace | Their organisation role, implicitly |
| Explicit member of a non-default workspace | The workspace role they were given (admin, builder, editor, viewer) |
| Everyone else | No access - the workspace 404s as if it didn't exist |
Membership on the default workspace can't be overridden per user - access there is always implicit.
Good to know