Search and filters
The board, backlog, and all-issues views share one search-and-filter input. It combines two kinds of matching — exact text and semantic — and composes with filters for tags, assignees, and columns.
Two kinds of matching
When you type a query, Can runs both predicates and shows the union:
- Direct matches — tickets whose title or key contains the text you typed. These run on every keystroke and keep their normal board order.
- Semantic matches — tickets whose meaning is close to your query, even when no words overlap. "auth broken" finds "Wire OAuth callback". Semantic search starts once your query reaches 3 characters, runs against the whole workspace's tickets server-side, and appends its extra results after the direct matches, closest first.
Each result carries a badge — direct, semantic, or both — so you can tell why it matched.
How semantic search works
Every ticket gets an embedding computed from its title, description, and comments; the embedding refreshes whenever any of those change. Your query is embedded the same way and tickets are ranked by similarity. Low-confidence matches are dropped rather than shown, so an empty result list means nothing in the workspace is close — not that you used the wrong words.
Semantic search is available to workspace members only; anonymous visitors on a public board get direct text matching.
Filters
Press F to focus the search input on any view. Next to the query you can add filter pills:
- Tag — show tickets carrying every selected tag.
- Assignee — show tickets assigned to any of the selected people.
- Column — on the all-issues view, restrict to selected columns.
Filters compose with each other and with the search query: a ticket must satisfy every active dimension to stay visible.
Searching from outside the app
The same semantic search is exposed to integrations:
- REST:
GET /v1/workspaces/{slug}/tickets:search?q=...— see REST API and OAuth. - MCP: the
search_ticketstool — see Hosted MCP server.