When users need to find something in a business application, they generally reach for one of two mechanisms: they type what they are looking for, or they narrow down a list by selecting from known categories. These are full-text search and filtered views, and they solve different problems despite often being confused or treated as interchangeable.
Full-text search works by matching a user's typed query against the text stored in records. The system looks through names, descriptions, notes, comments, document contents or any other free-text fields and returns results ranked by relevance. The user does not need to know which field contains the answer, only that the words they type might appear somewhere in the data.
Filtered views work differently. The application presents a set of fields — status, date range, region, assigned team, category — and the user selects values from each to narrow the list. Every result returned will match all the selected criteria exactly. The user needs to know which field matters and what value they are looking for.
The distinction matters because each approach imposes different requirements on your data, your infrastructure and your users' behaviour. Full-text search needs an index built from text content and a query engine capable of ranking results. Filtered views need well-structured data with consistent values in the fields users will filter on. If a status field contains "Complete", "Completed", "Done" and "Finished" across different records, filtering by status becomes unreliable until the data is cleaned up.
These two approaches are not mutually exclusive. Most mature business applications offer both: a search bar for when you know a word or phrase, and filter controls for when you know the attribute. The decision is not which one to build, but which one to prioritise, how much to invest in each, and where the boundary between them should sit for your particular users and data.
| Search decision | User impact | How to test |
|---|---|---|
| When full-text search is the right starting point | Full-text search is useful when records contain substantial unstructured text and users do not know the exact field or value they need. It lets them search across descriptions, notes and document content rather than choosing a predefined filter. | Test representative queries for relevance, permissions, spelling variation, empty states and response time using realistic data rather than a small demonstration dataset. |
| When filtered views are the right starting point | Filtered views suit situations where the data is structured, the categories are known and users need to answer specific operational questions. | An operations manager who needs "all orders in the last 30 days with status 'awaiting dispatch' and assigned to the Midlands warehouse" is describing a filtered view. |
| Performance and infrastructure implications | Full-text search at scale requires a dedicated search engine or at minimum a database with capable text indexing. | As record counts grow, query latency and index maintenance become real considerations. |
| Building search when filters would suffice | One of the most common oversights is implementing full-text search for data that is entirely structured and well-categorised. | If every record has a status, a type, an owner and a date, and users consistently find what they need by selecting from those fields, full-text search adds complexity without proportional value. |
When full-text search is the right starting point
Full-text search comes into its own when your data contains large volumes of unstructured text and users do not know the exact field or value they need. A support team searching ticket descriptions for "payment failed" does not want to select from a dropdown — they want to type the phrase and see every ticket where those words appear, regardless of whether the phrase sits in the subject line, the customer's message or an internal note.
Document management systems are another clear case. If users need to find a contract by searching for a clause or a supplier name buried inside the text, filtered views on metadata alone will not help. The search must reach into the document content itself.
CRM systems handling large contact databases also benefit. A sales manager typing "Johnson logistics Birmingham" expects to see the right record without navigating through industry, region and surname filters. The query crosses multiple fields, and the value lies in speed and convenience rather than precision.
When filtered views are the right starting point
Filtered views suit situations where the data is structured, the categories are known and users need to answer specific operational questions. An operations manager who needs "all orders in the last 30 days with status 'awaiting dispatch' and assigned to the Midlands warehouse" is describing a filtered view. Each criterion maps to a single field with a defined set of values.
Admin panels and reporting interfaces almost always start with filters. The questions are predictable: show me records by date, by owner, by status, by type. Users are not guessing; they are executing a routine query they run regularly. Filters also make it straightforward to count, sum or export the resulting set — operations that are harder to apply meaningfully to ranked search results.
Customer portals frequently rely on filtered views because the data sets are smaller and the categories are clear. A client viewing their invoices does not need full-text search across invoice line items; they need to filter by date, status or amount.
Performance and infrastructure implications
Full-text search at scale requires a dedicated search engine or at minimum a database with capable text indexing. As record counts grow, query latency and index maintenance become real considerations. Filtered views, by contrast, can often be served by standard database queries with appropriate indexes on the filtered columns, which are typically simpler to maintain.
If your application will hold tens of thousands of records with substantial text fields, discuss the search infrastructure with your development team early. The choice of database, the indexing strategy and whether a separate search service is needed will affect both cost and architecture.
Building search when filters would suffice
One of the most common oversights is implementing full-text search for data that is entirely structured and well-categorised. If every record has a status, a type, an owner and a date, and users consistently find what they need by selecting from those fields, full-text search adds complexity without proportional value. The mistake usually stems from assuming that search equals sophistication, when in practice a well-designed filtered view is faster to build, easier to maintain and more predictable for users.
Assuming filters work without consistent data
Filtered views are only as reliable as the data behind them. If a "priority" field allows free-text entry, users will type "High", "high", "Urgent", "H" and "Important" — and a filter set to "High" will miss most of them. Before committing to filtered views as the primary finding mechanism, check that the fields you plan to expose as filters use controlled values: dropdowns, enums or validated inputs, not open text.
Ignoring how users actually behave
Business owners sometimes decide on search versus filters based on what seems logical, without observing how staff actually look for information. A team that has always used Ctrl+F in a spreadsheet will gravitate towards a search bar, even if a filtered view would be more efficient. Conversely, a team accustomed to running pivot-table-style reports will expect filters and may not even notice a search box. Understanding existing behaviour helps you prioritise correctly rather than building the mechanism that looks better in a specification.
Not defining what happens with no results
Both approaches fail if the empty-state experience is poor. A full-text search that returns nothing should explain why — was the query too specific, misspelt, or is there genuinely no matching data? A filtered view that returns nothing should tell the user which criterion is eliminating all results, rather than presenting a blank table. This is an acceptance-criteria point that is easy to overlook during development and becomes immediately visible once real users start working with the system.
Key questions to raise with a supplier
- Which approach are you recommending as the primary finding mechanism, and why?
- For full-text search: which fields will be indexed, and will search reach into attached documents or only into database fields?
- For filtered views: which fields will be available as filters, and are those fields currently populated with consistent values?
- How will the two mechanisms interact if both are provided — does applying a filter also search within those filtered results?
- What is the expected query response time at the projected record count, and has this been tested?
- How are empty results handled for each mechanism?
What to verify before accepting the work
Test with real queries that your team actually uses. If your support staff habitually search for error messages, try those exact phrases. If your finance team filters by specific date ranges and statuses, run those exact combinations. Check that filters combine logically — selecting "status: open" and "assigned to: Sarah" should return records matching both, not one or the other. For full-text search, verify that results are relevant enough to be useful without manual sorting, and that common misspellings or partial terms do not silently return nothing.
Finally, confirm that the chosen approach is documented in the specification with enough detail for another supplier to take over or modify it later. The fields indexed for search, the columns available for filtering and the logic that governs how they interact should be recorded as part of the system's technical documentation, not left as implicit knowledge held by the original developer.