Share Services Across Workspaces

For an organization where more than one team works on the same service. A service - a service frame plus its modules, tasks, linked repository, runs, and sync - is owned by your account (organization). A workspace is a curated view that mounts the services it cares about. The same service can be mounted onto several teams' boards at once, where it is one shared subtree rather than a copy.

Why services are account-owned

Large orgs run many teams against the same set of services. Cat Factory models that directly:

There is one physical copy of a service's blocks, keyed by service. Every board that mounts it reads the same task list and the same state.
An edit on one board, whether adding a task, moving work to Done, or a run finishing, writes the same record every other mounting board reads, so boards never drift.
A connected repository is synced once per org rather than once per workspace, so mounting a service on a second team's board adds no extra GitHub traffic.

Mounting a service onto a board

Every top-level service frame you create is automatically registered as an account-owned service and mounted onto the board you created it on. To bring an existing org service onto another board:

Open the Add service menu in the board toolbar.
Pick a service from your org's catalog, the list of services any of your workspaces own.
It mounts onto the current board and its full subtree (frame → modules → tasks) renders immediately.

Each catalog entry shows a mount count, and a frame mounted on more than one board carries a Shared badge so it's obvious the work is visible to other teams.

Per-board layout

Only a service frame's board position and size are per-workspace, carried on the mount, not the block. Drag a shared frame on one board and it stays put on the others. The task and module positions inside the frame are part of the shared subtree, so everyone sees the same internal layout.

Unmounting

Unmounting removes a service from the current board only. It never deletes the service or its work; the service stays in the org catalog and on every other board that mounts it. Deleting a service frame (rather than unmounting) drops the account-owned service and every workspace's mount of it.

Archiving a service with open work

A service that still has unfinished tasks can't be destructively deleted. The delete action routes to Archive service instead, so you never hit a dead end mid-flight. Archiving hides the service and its whole subtree from the board while preserving every row; it is restorable at any time, with no expiry, from the toolbar's Archived services list. An archived shared service is hidden on every board that mounts it and can be restored from any of them.

Re-adding and deleting boards

Because a service is account-owned, importing a repo that already backs one mounts the existing shared service onto your board rather than failing with "already linked", and re-adding a repo already on the board is a no-op. Deleting a board reclaims the services it homes and their environments so the repo is immediately re-addable elsewhere; a service another board still mounts is re-homed to a surviving board (kept alive with its blocks and run history) rather than destroyed.

Live updates across boards

A change to a shared service, such as run progress, a bootstrap, or a notification, is fanned out to every workspace that mounts it, live over the same stream used for any board update. You don't need to reload to see another team's run advance on a service you both mount.

Recurring schedules on a shared service

A recurring pipeline attached to a shared service is visible on every board that mounts it, and its reused on-board task block renders on each. The schedule is a single record, so it fires once per org, no matter how many boards mount it.

Next: automate routine work with Schedule Recurring Work.