Workspaces
A workspace is the place you work in the hub. Everything you do happens inside one: every page you open is addressed by its workspace, and everything you make belongs to it. A workspace has the features it has been given, and nothing else. It is yours, or it belongs to an organization you are a member of, or it is a team's.
You are in a workspace as soon as you sign in. You switch to any other you can reach from the workspace menu in the header, and if you are an admin of the hub, the Admin workspace at /admin is among them. Logging out clears your recent items and returns you to the front page.
Topics
- What a workspace is: yours, an organization's or a team's, and what each kind offers.
- The address: what the address of a page says, and who sees what at it.
- Managing features: switching features on and off for a workspace.
- Workspace settings: what Settings shows for each kind of workspace.
- Members: an organization's roster and the roles its people hold.
- Organizations: creating one, archiving it and bringing it back.
- Transferring ownership: moving something you own to another workspace.
What you do with a workspace on the site, a program can do over the API: list the workspaces you can reach, read and change the features a workspace has, create and archive organizations and assign roles to members. It can also move what a workspace owns.
Workspaces are the workspaces routes. One call returns the workspaces you can reach, each as a slug, a name and a type, ordered individual, then organization, then team. Another lists the ones you have archived.
Features are the ecosystem routes. The feature catalog call lists every feature with its key, label and description, what it requires, what it comes with, whether it is for an ecosystem's own use only, and whether it is coming soon. One call lists what an ecosystem has, each marked provisioning, active or removed. One adds a feature by its key; it is written by hand rather than generated, because adding a feature has side effects. One removes a feature, and answers with a conflict when another active feature still requires it. One says which features can be added now.
Organizations are the organization routes. Deleting an organization archives it, and a restore call answers restored, not found or handle taken. Members' roles are assigned through the access routes.
Transfers are the ownership routes: one previews a move, and one runs it. A name collision in the target answers with a conflict.
The full list of routes, with each one's parameters, body and responses, is the REST reference on the help site. The tools an agent gets are listed in the MCP reference.
A workspace is a view, not a record. With no workspace record there is no second source of truth about who owns what. A workspace's branding and its features are read from its owner and the owner's ecosystem.
One address answers two questions. Is this yours, and is this a profile. That is why a member sees the workspace and a visitor sees a profile at the same address, and why a workspace you cannot reach looks exactly like one that does not exist.
The gate wraps everything. The check that decides member or visitor runs in the layout around every workspace page, so no feature's page is left unguarded.
/home is resolved in the browser. Finding your preferred workspace needs the preference your browser holds, which the server does not have.
The rail shows what the workspace has, not a fixed list. Each row is a feature switched on for that workspace. The older rail drew features a workspace could not use, and a row that leads to a placeholder is exactly what the rail must not show, which is why a coming-soon feature cannot be added.
Archive, never delete. An archive can be undone. A restore has to face the possibility that someone took the handle in the meantime, so it says so instead of overwriting.
A transfer preview changes nothing. Rehearsing a transfer and rolling it back held locks across two workspaces for most of a minute every time a dialog opened. Now the preview only reads, and the move undoes exactly what the preview named.
Names are refused, never auto-suffixed. A silently renamed object is worse than a refused move.