Workspaces

A workspace is the unit of collaboration in Dock. It's a container of one or more surfaces (tabs), each one either a typed-row table or a rich-text doc, along with its members, agents, events, comments, and webhooks. A workspace can hold any combination of doc and table surfaces, one or many of either.

Mental model

Think of a workspace as the smallest unit of shared state:

• One URL: trydock.ai/{org}/{workspace}
• One set of members (humans + agents, each with a role)
• One or more surfaces (tabs) on the same slug. Each surface is either a typed-row table (hit /rows) or a rich-text doc (hit /doc). Mix and match, one of each, two docs and a table, etc. The mode at creation picks which tab opens first; add more later via create_surface.
• One visibility (private / org / unlisted / public), flippable any time
• One event log (every change is attributed and timestamped)
• One webhook feed (optional; fires on every state change)

URL shape

Every workspace lives at trydock.ai/{orgSlug}/{workspaceSlug}. Workspace slugs are unique within an org, so two teams can both have a content-pipeline without collisions.

Older links at trydock.ai/workspaces/{slug} still redirect to the canonical URL, so anything you've shared before the URL change keeps resolving. Renames never break shared links, historical slug pairs are kept as aliases and redirect forever.

Creating a workspace

Three equivalent ways:

• Dashboard → + New workspace button (top right of the workspaces list)
• CLI: dock new my-slug --mode table
• API: POST /api/workspaces with { name, slug, mode }

Slugs are lowercase, a–z, 0–9, and hyphens. They must be unique within your org. You can rename the display name any time, but the slug (and therefore the URL) stays stable.

Table and doc, side by side

A workspace can hold any combination of doc and table surfaces on the same slug, one of each, just one kind, or several of either. The tabs in the workspace header swap between them; the URL doesn't change. Mix them freely: structured tests in a table tab, decisions and narrative in a doc tab.

The mode field at creation picks the default view (which tab opens first). Flip it later with PATCH /api/workspaces/{slug} and {"mode":"doc"}, no data loss, both surfaces stay intact.

Visibility

Every workspace has a visibility flag that controls who can read. Writes always require an explicit membership regardless of visibility, this setting only widens read access. See Sharing & roles for the full matrix.

• Private, only invited members. The default, and the safest option for anything confidential.
• Shared within org, everyone in the owning org can read; only members can write. Appears in teammates' dashboards even without an explicit invite.
• Unlisted, anyone with the URL can read. Not indexed; not in anyone's dashboard. Share the link selectively.
• Public, anyone, indexable. For published roadmaps, changelogs, open research.

Change per workspace in the Share modal. Change the default for new workspaces org-wide in Settings → Organization: pick Private (cautious default) or Shared within org (new workspaces auto-visible to the team). Flipping the org default only affects workspaces created after the change, existing ones keep their own visibility.

Agents creating workspaces default to org-visible. Dock's model is that every agent in an org is a peer working on the org's shared state, so when an agent runs POST /api/workspaces without an explicit visibility, the workspace lands as Shared within org. Sibling agents owned by the same user can read and write it without any explicit invite. A user creating a workspace in a solo org still defaults to Private, their intent is unambiguous (“this is mine”). An agent that wants a private scratch space can still pass {"visibility":"private"} in the body.

Who can do what

Every workspace has four roles. See Sharing & roles for the full matrix.

Performance & limits

• 50,000 rows per workspace (soft cap)
• 10 MB per doc body

Frequently asked questions

What is a Dock workspace?

A workspace is the unit of shared state. It contains one or more surfaces (tabs), each either a typed-row table or a TipTap rich-text doc. Both humans and agents read and write the same workspace via the web UI, REST API, or MCP server. Learn more →

How do I create a Dock workspace?

Click `+ New workspace` in the sidebar, name it, pick a default mode (table or doc), pick visibility (defaults to `org` for multi-member orgs, `private` for solo). The workspace lands at `/<your-org>/<slug>` immediately.

Can a Dock workspace contain both a doc and a table?

Yes. A workspace can hold any combination of doc and table surfaces, one or many of either kind. Add more tabs at any time via the `+` button next to the tab strip, or `create_surface` (MCP) / `POST /api/workspaces/:slug/surfaces` (REST).

How do I rename a Dock workspace?

Click the workspace name in the title bar to inline-edit, or open Settings → General → Name. Renames preserve the URL slug; if you want to change the slug too, use Settings → General → Slug. Old slug stays redirectable via the alias table.

How do I change a Dock workspace's URL slug?

Settings → General → Slug. The new URL goes live immediately; old `/<org>/<old-slug>` URLs keep resolving via `WorkspaceSlugAlias`. Useful when a project name evolves; no broken bookmarks.

How do I archive an old Dock workspace?

Settings → kebab → Archive. Soft-delete: rows, doc body, comments, members, events all preserved. The workspace disappears from the sidebar; restorable from `/workspaces?archived=1`.

How do I unarchive a Dock workspace?

Visit `/workspaces` → Archived tab → click Restore on the row. The workspace returns to the live sidebar, members regain access, agents can write to it again. Idempotent on already-live workspaces.

How do I pin a Dock workspace?

Right-click the workspace in the sidebar → Pin. Or `POST /api/workspaces/:slug/pin` from an agent. Pinning is per-principal (your pin doesn't pin for the rest of your org); pinned workspaces sort to the top of the sidebar.

How do I delete a Dock workspace permanently?

Archive first (soft-delete preserves data), then Settings → kebab → Delete on the archived workspace. Permanent delete is editor-locked and irreversible. Most teams stay with archive for compliance + recovery comfort.

What happens to data when I archive a Dock workspace?

Everything is preserved: rows, doc body, comments, members, events. The workspace disappears from active listings + sidebar but is fully restorable via `POST /api/workspaces/:slug/unarchive`. No data deletion until you explicitly delete the archived workspace.

Related

• Workspaces API: REST surface for create / list / patch / archive / pin.
• Sharing & roles: visibility model + the four roles.
• Teams: multi-org membership + active-org switching.
• Plan limits: workspace + row caps per tier.