Cross-workspace search

Overview

Cross-workspace search (WB.21) lets a user with membership in more than one workspace — or a platform admin with membership in every workspace — search across all of those workspaces from a single query. The result list is grouped by workspace so you can quickly tell which one a hit lives in. The Command Palette (Ctrl/Cmd+K) integrates with it: when the user is multi-workspace, the palette adds a "Search across all your workspaces" row at the bottom that switches to the cross-workspace mode.

The endpoint is GET /api/v1/platform/cross-workspace-search/?q=.... It returns a list of {workspace_slug, workspace_name, entity_type, entity_id, title, snippet, score} records, grouped client-side by workspace_slug. Searchable entity types include changes, incidents, hosts, certificates, projects, tasks, runbooks, and knowledge articles.

Why it exists

A workspace-scoped search is correct for day-to-day operational work — you do not want results from a peer team's incidents polluting your view. But there are real moments when you need the wider scope:

• "Where did we already write a runbook for this Postgres failover scenario?" — you remember the runbook exists somewhere in the org but not in which workspace.
• A platform admin is on an incident bridge and needs to find every change in the last hour that mentioned a specific service.
• You moved teams last quarter and your old workspace has the answer you need today.
• An auditor asks "show me all changes across the org that touched production database X" — workspace-by-workspace search is too slow.

The cross-workspace search exists for those moments and exits stage-left for normal scoped search.

Key concepts

• Endpoint — GET /api/v1/platform/cross-workspace-search/?q={query}&types={type1,type2}&limit={n}. Default limit is 50, max 200. The types parameter is optional; omit it to search all entity types.
• Access rule — The endpoint only returns hits from workspaces the caller is a member of. A platform admin is implicitly a member of every workspace for the purposes of this endpoint. A non-platform-admin with two memberships will see hits from those two workspaces only. A non-platform-admin with one membership gets a 403 with code='requires_multi_workspace_or_platform_admin'.
• Per-workspace RLS context — The endpoint loops over the caller's eligible workspaces, sets the RLS GUC for each, runs the search, then unions the results. RLS is never bypassed — the caller sees exactly the rows they would have seen by switching workspaces manually and searching there.
• Result grouping — The API returns a flat list scored across all workspaces. The UI groups by workspace_slug in the order of best-scoring match per workspace, so the workspace whose top hit is best ranks first.
• Command Palette integration — The palette (Ctrl/Cmd+K) detects multi-workspace eligibility on open. When eligible, it shows a "Search across all your workspaces" row pinned to the bottom of the suggestion list. Selecting it switches the palette into cross-workspace mode for the rest of the session.
• Highlighting — Snippets include <mark> tags around the matched query terms. The UI styles <mark> with a yellow background for visibility.

Common workflows

1. Find a runbook you know exists somewhere

1. Press Ctrl/Cmd+K to open the Command Palette.
2. Start typing the runbook subject ("postgres failover").
3. Notice the bottom row: "Search across all your workspaces". Click it (or press the indicated chord).
4. The palette switches to cross-workspace mode. Results are grouped by workspace; runbooks have a book icon.
5. Click the result to navigate; the URL contains the source workspace slug so you land in the correct workspace.

2. As a platform admin, find every change that mentioned a specific service

1. Open Platform → Search (or use the palette).
2. Enter the service name (e.g. payments-api).
3. Filter the type chip to Changes.
4. Each grouped section is one workspace. Expand to see all hits in that workspace.

3. Confirm coverage of an incident postmortem across teams

1. Open Platform → Search.
2. Enter the incident keyword or service name.
3. Filter to Incidents + Runbooks + Knowledge.
4. The result shows which workspaces have done the work and which have not — a workspace that has incidents on the topic but no runbooks or knowledge articles is a documentation gap.

4. Limit search to a subset of workspaces

The API does not accept a workspace filter parameter (by design — the access rule already constrains it). To narrow scope, leave the cross-workspace mode and run the normal workspace-scoped search in the workspace you care about.

Permissions

Per-result RLS still applies — if a row in workspace X is hidden from the caller by row-level policy (e.g. self-visible-only rows belonging to another user), it never appears in the cross-workspace result.

Troubleshooting

The "Search across all your workspaces" row never appears in the palette. You only belong to one workspace, and you are not a platform admin. Have an admin add you to a second workspace or grant the role.

A result links to a workspace that 404s. You were removed from that workspace after the search ran. Refresh the palette and retry; the result list is rebuilt against your current memberships.

Search is slow when I have many workspaces. The endpoint runs sequentially per-workspace. For users with >20 workspaces (typical platform admins), the request can take several seconds. The API streams partial results in newline-delimited JSON when the Accept: application/x-ndjson header is set; the UI uses this and renders workspaces as they arrive.

No results across workspaces I know contain a match. Confirm the entity type is included (use the chips). Some entity types — notably audit log entries — are not indexed for cross-workspace search by design; use the per-workspace audit log instead.

Snippets have <mark> literal text instead of highlighting. The API returns HTML-style tags in snippets. The default UI renders them; embedding the result in a CSV or raw text export will show the literal tags. Strip tags client-side if needed.

Related articles

• Executive dashboard — the data view for the same multi-workspace scope.
• Workspace templates — useful for ensuring searches return consistent results across workspaces.