MDocs
Open app

Organising across spaces

Name spaces so people can find them, share canvases between spaces instead of duplicating, and use crossposting to bridge conversations.

A workspace usually grows to dozens of spaces. The default sidebar list becomes hard to navigate when every team, project, and side-channel has its own room. This guide is about the choices that make the whole set of spaces navigable, not the contents of any one space.

Name spaces so they sort themselves

Space names are the only handle people have when scanning the sidebar or browsing public spaces. A few naming patterns we have seen work well:

  • Prefix by domain. eng-, design-, sales-, ops- — short prefixes group every space for a team next to each other in any alphabetical sort. Prefer prefixes to suffixes; people scan from the left.
  • Use full words, not initials. eng-platform reads cleanly even for people not on the team; eng-pl does not.
  • Reserve -private, -leads, -ops suffixes for restricted variants. When you have a public discussion space and a private leadership one, putting them next to each other (product, product-leads) makes the relationship obvious.

A space name is not permanent. Renaming is cheap and re-shapes the sidebar for everyone — do it whenever a name stops describing what the room is for.

Public by default, private by exception

Public spaces are how knowledge spreads through the workspace. Anyone in the workspace can find them, hover-preview them in the space browser, and join. Default new spaces to public unless there is a specific reason not to.

Use a private space when:

  • The membership itself is sensitive (personnel, customer incidents, security work).
  • A small project group genuinely benefits from a quiet room and would feel watched in public.
  • The work is pre-announcement and a leak would matter.

Many projects start private and graduate to public once the work is shippable. If you start in the wrong place, recreating the discussion in a fresh space later is much more work than starting open and locking down only when you have a real reason.

Share canvases instead of duplicating

A single canvas can live in more than one space. From a canvas tab, right-click and pick Share to space to link it into another space. The canvas now appears in both spaces' tab bars, and edits made in either space are reflected in both — there is one canvas, two locations.

Patterns this enables:

  • A spec lives in eng-platform and product. Product reviews in-place; engineering edits in-place; nobody is reading a stale copy.
  • A roadmap database lives in leadership, eng, and design. Each team filters the same data through their own preferred view without forking it.
  • A runbook lives in the team's space and a hub incidents space. On-call people find it from the place they look first.

Prefer linking a single canvas over copying its content. If two spaces are reading and editing the same source of truth, they should be looking at the same row in the database, not at a Slack-style "I copied this for visibility" forward.

When a canvas is linked to more than one space, the same right-click menu offers Remove from space — that only unlinks the canvas from the space you are in; it stays put everywhere else. When a canvas lives in just one space, the menu instead offers Archive.

Archive a canvas you no longer need

Right-click a canvas tab and pick Archive to retire it. Archiving hides the canvas from the tab bar and from the #-mention picker, but its content — every document, database row, comment, and version — is kept, not deleted. You can still reach an archived canvas by its direct link, so the work is never lost the way a hard delete would lose it.

Crosspost messages when a thread spans spaces

When you compose a message you can pick additional target spaces. A crossposted message is one message that exists in each of the chosen spaces — replying in any space adds to the same thread, and reactions are aggregated across all of them.

Use crossposting when:

  • You are announcing something one team owns to several teams that consume it.
  • A question genuinely belongs to two teams and would otherwise be asked twice.
  • You want a thread visible to a wider audience without inviting everyone into the same space.

Avoid crossposting as a substitute for joining the right space. If every message you send to a space is a crosspost, you (or the audience) probably belongs in that space full-time.

Combine folders with multi-space sharing

Folders in the tab bar are a per-space view of a workspace-wide relationship. A canvas can belong to a folder in one space and appear top-level in another, or belong to different folders in different spaces. The grouping reflects how each space wants to read the canvas, not where the canvas "lives".

Concretely: drop the same database into two spaces, then drag it into a folder in the first one only. The second space sees it as a top-level tab; the first sees it nested inside the folder. Each space's tab bar matches that team's mental model without forcing the other team to agree.

Hub spaces for cross-cutting topics

Some topics — incidents, hiring, documentation, an all-hands — genuinely span every team. For those, set up a single hub space that everyone joins, and link the relevant canvases into it from each team's home space. The hub becomes the default place to look up "what's the latest on X" without people having to remember which team's room owns the canonical copy.

Avoid hubs for topics that don't span every team — a hub that only a few people use crowds the sidebar without paying for itself.

Archive old spaces, do not delete

Spaces you no longer use can be archived from settings. An archived space becomes read-only, drops out of the active sidebar, and stops collecting new messages — but its history is preserved and searchable. Prefer archiving to deletion: a search hit on a two-year-old decision is more valuable than the saved sidebar slot.

  • Spaces → Overview for the public/private distinction and membership basics.
  • Spaces → Organising a space for folders, tab order, and document-vs-database choices inside a single space.
  • Messaging → Sending messages for crossposting and mentions.
  • Canvas → Overview for how multi-space canvas sharing works at the canvas level.