Why does my saved search only show 500 rows in the browser?

Because the results page renders a fixed 500-row window, and nothing on the page tells you that is what you are looking at. The search ran in full, the Total at the bottom is correct, and the table under it stops at 500 rows without a marker of any kind.

Minimal reproduction

Run a saved search that returns far more rows than a screen can hold, open its results page, and count the rows in the rendered table.

/app/common/search/searchresults.nl?searchid=

That gave 501 table rows: one header and 500 data rows. Then the same URL with a page size asked for explicitly:

/app/common/search/searchresults.nl?searchid=&size=100
/app/common/search/searchresults.nl?searchid=&size=1000

Both returned the same 500 data rows, and the same page weight as the default to within a byte or two. The size parameter did nothing at either end of the range. Whatever number goes in, the window is 500.

There is no warning anywhere on the page

The rendered page was scanned in full for every plausible phrasing of a truncation notice:

/exceed|too many|maximum|limit|only the first|truncat/i

Nothing matched. There was no "showing 1 to 500 of N" marker at the boundary, and no pagination control that the scan could find in the rendered markup. The only number on the page is the Total, which is correct and which is exactly what makes the page misleading: it states the true size of the result set and then shows a small fraction of it. A user who scrolls to the bottom of that table has no way to tell that the data stopped rather than ended.

The failure is not that the browser caps the view, which is reasonable. The failure is that the cap is invisible, so a page that is missing most of its rows looks identical to a page that is complete.

The export is complete, which is the opposite of what people expect

Export the same search to CSV from the same results page and you get every row. The exported data row count matched the reported Total exactly, with no truncation, in a file produced in a couple of seconds.

So the ranking is: the UI is the lossy surface and the export is the faithful one. The common fear runs the other way, that the export quietly truncates like the screen does, and in this run it did not. If you need the data, export it. If you need the number, read the Total, not the table.

Anything read by eye off the rendered table is read off 500 rows drawn from a much larger set: spot-checking whether a record appears, judging how many rows match, eyeballing the spread of values. This run did not establish which 500 rows the page keeps, so nothing about the remainder of the result set can be inferred from them.

There is a version of this in the other engine too. SuiteQL's REST envelope reports a totalResults figure that is a cap rather than a count, described in why totalResults does not match SELECT COUNT(*). Same shape of problem, opposite polarity: there the number lies and the rows are honest, here the number is honest and the rows are short.

How to tell if you are affected

Open the results page and compare the Total against the number of rows actually rendered. If the table ends at exactly 500 and the Total is larger, you are looking at the window.

The audit worth running once: go through the saved searches your team eyeballs in the browser rather than exports, and check which of them return more than 500 rows. Every one that does has been showing a partial answer to everyone who opened it, with nothing on the page saying so.

If a search needs to be readable on screen, narrow it with criteria or group it so the result genuinely fits, rather than relying on a view that silently stops.

Scope: one sandbox account on NetSuite 2026.1, Administrator role, a single Transaction saved search. This probe was UI-driven: the results page was fetched and its rendered markup parsed, and the CSV came from the Export - CSV button on that same page. The 500 figure held across the default page size and the two explicit size values tried. Whether some other parameter or preference moves that window was not tested here.