The Saved Search Was Never Free

Where the Reruns Come From

The most common culprit is the home dashboard. A saved search pinned as a portlet reloads every time a user opens NetSuite, every time they navigate back to the home tab, and on any manual refresh. Multiply that by fifteen users who all start their morning on the dashboard and you have hundreds of executions before 9 AM — on a single search.

KPI scorecards and KPI meters are worse. We've seen home dashboards with eight KPIs, each backed by a separate saved search with summary grouping and a formula column computing a ratio. Every page load fires all eight. That is not a dashboard, that is a scheduled assault on your account's concurrency limit.

Then there are the less visible sources: user event scripts calling search.load() in their before-submit or after-submit entry points, running on every save of a record type that gets touched constantly; Map/Reduce jobs that load a base search and iterate it in chunks; nested saved searches where search A drives the record set for search B. Scheduled searches emailed daily, fine on their own, except the email job also triggers at the top of every hour because someone set the frequency wrong and never noticed.

None of that shows up on the search itself. You just see the timeout.

Why It's Expensive When It Does Run

A saved search with formula columns is not a simple SELECT. Every formula column re-evaluates per row, per execution. A case/when expression across a joined field on a large result set is doing real work. Add a summary type — sum, average, group — and you have pushed aggregation down to the database layer on a result set that may not be filtered tightly enough to make that fast.

Joins make it worse. A search joining Transactions to Transaction Lines to Items to Custom Records is four tables deep before any filters apply. Run that four hundred times a day and you are not running a report, you are running a query engine at scale.

Page loads stall because every portlet reload blocks the dashboard render until the search completes. Account concurrency tanks because NetSuite limits simultaneous search executions, and heavy searches held open by slow formula evaluation consume those slots. Scripts calling those searches burn through scheduled script time limits faster than anyone expects.

We had a client whose nightly Map/Reduce was timing out on governance. The script itself was efficient. The saved search it loaded had eleven formula columns, no result cap, and was returning three times more records than it needed because the date filter was set to "all time" since go-live.

How to Find the Offenders

Go to Application Performance Management and look at Search Performance. Sort by execution count, not by execution time. High execution count plus high average duration is a problem you can quantify.

Check home dashboards — not yours, everyone's. Role-specific dashboards in particular. Portlets are easy to add and nobody removes them. Ask your admins to audit portlet configuration across every role.

Searches with heavy formula columns are easy to spot — look for CASE, DECODE, or arithmetic expressions in the Results columns. Those are the ones where a smarter filter has the biggest payoff.

What to Do About It

Trim columns first. Every column a saved search returns costs something. Formula columns cost more. Remove anything not used in the actual output — especially on searches backing portlets, where users often see three columns of a result set returning twelve.

Add real filters. "Transaction date is within this fiscal year" is not a filter, it's an apology. If a portlet is meant to show open purchase orders over a dollar threshold, filter to that exactly.

Cap results. search.run().getRange() in a script has a limit, but the saved search itself does not. Use the Results: Return Maximum field in the search definition to bound what the database has to assemble.

Move heavy aggregation off live portlets. Run a scheduled script nightly that executes the expensive grouped search, writes summary totals to a custom record, and point the portlet at that summary record instead. The dashboard reads one record. The heavy search runs once.

Stop calling search.load() inside user event scripts on record types with high transaction volume. If you need a count or a lookup, use N/query with a targeted SuiteQL statement. It is faster, more predictable, and easier to govern.

Bottom Line

The saved search was never free. It just billed somewhere you weren't watching.

Page loads. Script timeouts. Concurrency blocks. That's where the cost lands.

The search that ran "occasionally" in your head ran four hundred times yesterday. Finding it takes twenty minutes in Application Performance Management. Fixing it usually takes less than an hour.

The report was always expensive. Now you know where to look.