The Nine-Minute Revenue Saved Search

The slowest parts are the criteria, not the row count:

• TO_CHAR({trandate}, ...) in a criterion is a function on a field, which prevents NetSuite from using the indexed date column to restrict the result set. The search scans far more transaction lines than one month's worth.
• UPPER({customer.companyname}) applies a function across a joined table, forcing a join-level scan and blocking index use on the customer name. A 'does not start with TEST' condition on the raw field, or better a custom 'Test Record' checkbox, would be selective and index-friendly.
• Six joins with eight summary columns produce a large GROUP BY across Customer, Sales Rep, Item, Class, Subsidiary, and a custom record. Each join multiplies rows before aggregation; the custom-record join is usually the expensive one because it is a separate table without a direct index path from transaction lines.
• Run-as and audience settings matter too: a search running as an administrator bypasses role-based filtering, while a search running as each user with subsidiary restrictions can be re-planned per user and time out for some but not others - which matches the 'fails for some users' symptom.

Replace the anti-patterns, then split by audience:

• Date: use a relative date filter ('this month' / 'this fiscal month') instead of a TO_CHAR formula. This restores index use and removes a per-row function.
• TEST exclusion: add a custom customer checkbox or a customer category and filter on it directly; if you must keep a name test, use a 'does not start with' condition rather than UPPER().
• Trim joins that are only there for filters into criteria on the transaction instead; move the contract-terms custom record out of the main search and into a secondary report if it is not a displayed column.
• Split the audience: a core search (six columns) for all 30 users, and a second search or SuiteAnalytics Workbook pivot with the sales rep breakdown for the two users who need it. Finance loses no data; each user gets a smaller, faster result.
• Consider SuiteAnalytics Workbook for the month-end view: the semantic layer handles transaction-to-customer joins and aggregation more predictably, and the pivot can be exported and scheduled.

Test each change in sandbox and compare totals to the existing report to prove nothing shifted.

The failure is a delivery design problem as much as a performance one:

• Move the schedule to a completed report rather than a live search. Generate the CSV/Excel at 04:00 to a file cabinet location and email the file, so recipients are not each executing the search at 07:00. Stagger schedules if multiple reports share the window.
• Reduce the blast radius. One failing user's role-based execution should not break 30 inboxes; schedule as a single owner and distribute the output.
• Add failure detection. A scheduled-search failure should raise a case or notification to the analytics owner, not be discovered when a user complains. Track runtime over time.
• Apply the same review to other scheduled searches - this one almost certainly has siblings with the same TO_CHAR formula pattern.
• Document ownership and a performance budget: any saved search scheduled to more than ten users gets reviewed for formula criteria, join count, and run-as behavior before publishing.

Finally, confirm the result set stays inside NetSuite's result limits; a report that exceeds them silently truncates, which is worse than an email that fails visibly.