Search inside your application
Users expect to type a few words and find the record. What application search needs, and when a database query is not enough.
The short answer
Users of any application expect one thing from search: type a few words, find the record. Behind that expectation is more than a database query. Search has to be fast enough to show results as the user types, tolerant of typos and partial words, aware of what this user is allowed to see, and able to look across customers, orders, documents and everything else from one box. A database handles exact lookups well. Real search across text, with ranking and typo tolerance, usually needs a search index kept in sync with the data. And because search looks across everything, it is where permission mistakes surface first, so results must be filtered by the user’s rights on every query.
What application search needs
| Need | Why | How |
|---|---|---|
| Speed | Results as the user types, or search is abandoned | An index built for search, not a table scan |
| Typo tolerance | People misspell names and paste identifiers with extra characters | Fuzzy matching and partial matching in the index |
| Relevance | The most likely record first | Ranking by field weight, recency and exact matches |
| Cross-type | One box for customers, orders, documents | A unified index with a type per result, grouped in the interface |
| Permissions | Users see only what they may | Filter by the user’s scope at query time; never index restricted fields |
| Freshness | A record created a minute ago is findable | Index updates on every change, with a reconciliation job |
| Insight | Improve it over time | Log queries, empty results and clicks |
Building it
- Decide what is searchable per record type, and which fields matter most.
- Choose the approach: database full-text features for modest needs, a dedicated search service for real text search at scale.
- Index on change, with a nightly reconciliation so the index never drifts from the database.
- Apply permissions at query time, using the same scoping layer as the rest of the application.
- Design the results: grouped by type, identifier and key detail visible, keyboard navigable, one click to the record.
- Log queries and empty results; review monthly and adjust fields and ranking.
Where AI fits
For structured records, classic search with good ranking is what people want: fast and predictable. For a body of documents, policies, manuals, past reports, semantic search that understands a question in plain language adds real value, often combined with an assistant that answers from the retrieved passages. The two coexist: one box, structured results first, document answers where the query looks like a question.
What this means for you
Treat search as a feature with its own design: an index kept in sync, typo tolerance, ranking, one box across record types, permissions applied on every query, and a log that shows what people could not find. Users judge an application by whether they can find things in it. Search built to that standard is one of the most appreciated features in any system, and one of the most often neglected.
Frequently asked questions
Can we just use the database's search?
For exact lookups by identifier, name or email, yes, with the right indexes. For free text across many fields with typo tolerance, ranking by relevance and instant results as the user types, a database query grows slow and crude. A dedicated search index, updated when records change, handles that well and is a standard part of application infrastructure.
How do we keep search from leaking data?
By filtering every search by the user's permissions at query time, using the same rules as the rest of the application, and by never indexing fields the user role cannot see. Search is where permission bugs surface first, because it looks across everything. It needs the same scoping discipline as every other query, applied centrally.
What should the search box search?
What people are looking for when they type, which is usually a record: a customer, an order, a document, an invoice. One box, results grouped by type, the most likely match first, with the identifier and a key detail visible. Watch what people type and what they click; the log tells you which fields to index and which results to rank higher.