Permissions inside the query
Access checks are part of the database query, not a filter applied to a wider result. There is no over-broad set to forget to narrow.
The foundation under itProduct intelligence
Workspace search
Nine kinds of record, and only what you may open.
One search covers organizations, projects, documents, tasks, playbooks, companies, forms, automations and dashboards, together or one at a time. Membership checks are joined into the query itself, so a row you may not see is never fetched in the first place. Results cap at twenty, so the search box cannot become a load problem.
9kinds of record you can search3composable resource groups20ranked results at most
13 of 22 in The foundation under it
Product example
See it working
This is the same visual component used by the authenticated app, rendered with deterministic sample data.
Scenario
viewport
surface theme
mode
Scoped results
Results include only the organizations, projects and documents you can already open.
Inert sample data · no network access
Results
3 results · “pipeline”
↑↓to move↵to open
Preview ready
Highlights
Why it matters
Bounded on purpose
A query is 1 to 100 characters, results cap at 20 globally ranked matches, and wildcard characters are escaped before any database work starts.
Types, groups and one registry
Search one registered type, a named group, or any combination. The registry records what is searchable, by whom, and with what limits.
The problem this solves
Without a shared foundation, every team rebuilds these edge cases, differently.
The filter someone forgot
Search that fetches broadly and filters afterwards will eventually miss a path. Joining the membership check into the query means the rows were never fetched, so there is nothing to leak.
The query that becomes an outage
Without caps, one very long query or one enormous result set turns our own search box into the thing that slows everything down. Hard limits on length and results prevent that.
Search nobody can describe
When nothing records what is searchable and under which permission, every new feature reinvents search and re-argues access from scratch. One registry answers it once.
How it works
The mechanism end to end, as implemented in the repository.
- 1
Input is validated first
Query length, requested types and groups, filters, sort and result limit are all checked, and wildcard characters are escaped, before any database work begins.
- 2
The server picks the scope
Your active organization and project come from the session. The browser never decides whose records are searched.
- 3
Permissions join the query
Membership predicates are joined into the search itself, so candidate rows are narrowed before matching and ranking run.
- 4
Only selected lanes run
Groups and explicit types resolve to one canonical set. Only those authorized lanes execute, and their results receive a single global relevance order.
Engineering guarantees
What this does and does not promise
Safety boundary
Finding something is not permission to open it. Every feature checks access again when you open or edit the result. Meetings, decisions, objectives, campaigns and finance entries are not indexed today; companies and playbooks are the Growth Kit records search reaches.
Implementation evidence
The boundary above is code, not a claim. These files carry the contract:
src/db/postgres-search.tssrc/registries/search-indexes.tssrc/features/search/targets.tssrc/features/search/server.ts
Questions
Frequently asked questions
Used alongside this
These capabilities share contracts and boundaries with this one.
What workspace search rests on
The docs describe the same contracts this page demonstrates.