> ## Documentation Index
> Fetch the complete documentation index at: https://docs.korint.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Search & list views
> How Korint's search engine powers portfolio lookups, list views, filtering, and autocomplete across the platform.
Every portfolio list and lookup in Korint is powered by a single search engine. When a broker types a customer's name into the search bar, filters a policy list by status, or opens a list view of unpaid invoices, they are querying the same underlying index. This is what lets brokers find a policy or a customer in a few keystrokes and keeps list views fast even on large portfolios.
***
## What is indexed
The search engine indexes the platform's major business entities into searchable **collections**. Each collection holds one type of record, kept up to date as records change:
* Customers
* Policies
* Assets
* Invoices
* Payments
* Documents
* Brokerage firms
* Distribution requests
* Alerts
* Compliance checks
* Derogations
Indexing each entity type into its own collection is what allows a single search bar to return the right kind of result and each list view to be scoped to exactly one type of record.
***
## What you can do with it
Free-text search across a collection — type a name, a reference, or a fragment and get matching records back.
Faceted filtering by status, product, dates, and the product's own custom fields, so a list view can be narrowed to precisely the records that matter.
A count of matching records for a query, used to show totals and drive pagination on list views.
Type-ahead suggestions as a user types, surfacing likely matches before they finish their query.
Because custom fields are indexed alongside the built-in ones, list views can filter on the fields that are specific to each product — not just on generic attributes like status or creation date.
***
## Tenant isolation and freshness
All results are **tenant-scoped**. A search only ever returns records belonging to the tenant making the request, so one tenant can never see another's customers, policies, or documents through search.
To keep list views responsive, search results are **cached per tenant**. The cache is invalidated automatically when the underlying records change, so a newly created policy or an updated customer status appears in search and list views without anyone having to refresh an index manually. The cache is a performance layer only — it never widens what a tenant can see.