Lists: Search the Whole Warehouse, Not Just the Rows on Your Screen
The pagination contract behind every top-level list, and why an empty page is never allowed to lie about your inventory.
An operator types a serial number into the inventory search and gets nothing. The asset exists. It is on page fourteen. The search only looked at the twenty-five rows the browser had loaded, and the operator now believes the device was never received. Half an hour and one awkward phone call later, it turns out it was. That failure mode is the reason every top-level list on the platform follows one rule: search first, paginate second.
The contract
Search and filters are applied to the full dataset of the list before the page is chosen. What you see is the current slice of everything that matched, never a filter over a slice. The list tells you so: the matching total, the current range, page X of Y, direct jumps to nearby pages and a page-size selector. The default page size is a tenant-wide setting under Settings > Display & lists, so a team that prefers a hundred rows per page decides that once, for everyone.
The address bar remembers
The URL carries the search text, the filters, the sort, the page and the page size. Refresh, and you are where you were. Send the link to a colleague, and they see the same working set. Open an asset, fix its grade, come back — same page, same filters, same row order. A list that forgets its state on every detour is a list people stop trusting after one morning.
Two kinds of empty
“No records” and “no matches” are different sentences and the platform says the right one. A tenant that has not received a single asset yet sees a first-run empty state that points at receiving or an inbound manifest as the first operational step. A tenant with ten thousand assets and a filter that matches none sees a no-results state that asks them to widen the search. And a page number beyond the end of the list — a stale bookmark, a shared link after a cleanup — is never allowed to pretend the tenant has no data. An empty page is an answer, not an accusation.
Pickers play by the same rule
Operational pickers that feel like a stock list — choosing source assets for a demanufacturing job, selecting free inventory for an outbound order — search across every candidate, not just the ones that fit on the first screen, and start from the same default page size. If a picker can grow past a handful of records, it behaves like a list, because to the person on the floor it is one.
The two exceptions, named
Large feed-style screens such as the Activity audit trail use cursor paging — newer, older — as an explicit exception, because a total across millions of events is not the question anyone asks there. Small, bounded configuration lists that are fully loaded — a tenant’s pallet formats, its zone types — may filter in the browser, because there is nothing on a next page to miss. Everything else pages the way described above. No silent fallbacks to “previous / next” where a real total was possible.
Rows you can open without a mouse
Every row in one of these lists is a single named link to its detail. Tab lands on the row, Enter opens it, and a screen reader hears the record’s name once — “Acme BV, link” — not once per cell and not just “link”. Actions that appear when a mouse hovers a row appear on keyboard focus too. The list is the working surface of the day; it works with whatever hand is free.