Can I use a formula as an Available Filter on a saved search?

You can select one, and you can never make it work. The Filter dropdown on the Available Filters sublist offers Formula (Date), Formula (Numeric) and Formula (Text), so the option is there. What is not there is anywhere to type the expression.

Four columns, and none of them is a formula

The Available Filters sublist has exactly four columns, in this order:

Filter (select)   Show in Filter Region (checkbox)   Show as Multi-Select (checkbox)   Label (text)

The Criteria sublist, on the same form, has a column labelled Formula, element filterformula. That is the box you type an expression such as {quantity} * 2 into, and it is the reason a Criteria formula works at all.

Available Filters has no equivalent. Pick Formula (Text) from its dropdown and the line is complete as far as the form is concerned: a filter type, two checkboxes and a label. The expression the filter would evaluate has no home on that row and cannot be supplied through the supported UI. It is a dead end presented as a working option.

It saves anyway, which is what makes it a trap

The search was saved with a Formula (Text) available filter carrying no expression whatsoever. No validation error, no warning, no prompt for the missing formula. The page redirected to the Saved Searches list exactly as a clean save does, and re-opening the search shows the line still there, Formula (Text) in the Filter column and the other three columns empty. The line persists server side.

Put that next to what the Criteria sublist does with a formula it dislikes. A criteria formula naming a field that does not resolve is rejected instantly and loudly, with INVALID_FORMULA_FIELD and a message telling you to go back and correct it, before a single row is read. That behaviour has its own page.

So one form, on two sublists a tab apart, holds both that instant rejection and a path that accepts a filter which cannot possibly function.

Results can display formula types that nothing can filter on

The same probe read the option lists out of each sublist's own dropdown object rather than by eye, and the three lists do not match.

Results offers seven formula types:

Formula (Currency)   Formula (Date)   Formula (Date/Time)   Formula (HTML)
Formula (Numeric)    Formula (Percent)   Formula (Text)

Criteria and Available Filters offer three: Formula (Date), Formula (Numeric), Formula (Text).

Currency, Date/Time, HTML and Percent are display-only. A report can show a currency formula or a percent formula in a column and can never filter or restrict on one. There is no message about this and no greyed-out entry. The only signal is an absence from a dropdown long enough that nobody reads it to the end.

The asymmetry is wider than formulas. Results also exposes roughly twenty more fields overall than Criteria and Available Filters do, so the general rule to carry around is that displayable and filterable are different sets, and Results is the larger one.

What was not established

Whether such a filter does anything when it is actually filtered on was not determined, and this page is not going to guess.

With Show in Filter Region left unchecked, the saved filter did not render in the results page filter region. That is the documented meaning of the checkbox and not a finding. The attempt to re-open the saved line, tick the box and save again did not complete: the inline sublist editor stopped responding after loadline, the tab had to be navigated away to recover, and nothing from that attempt was saved. Server state was unchanged, because the only successful save was the first one.

So two halves, with different confidence. That the option is offered, that no expression can be attached to it through the UI, and that NetSuite saves the resulting filter without complaint are all established. What the filter does at run time is not.

What to do instead

Put the expression in Criteria, where there is a Formula column to put it in, and accept that the restriction is baked into the search rather than exposed to whoever runs it. If a user needs to vary the value, the thing that varies has to be a real field on the Available Filters list, not a formula.

Scope

One sandbox account on NetSuite 2026.1, Administrator role, one Transaction saved search created for the probe and deleted afterwards. This one was UI-driven: the sublist columns and the formula types above were read out of the saved search form's own dropdowns at /app/common/search/savedsearch.nl, not inferred from documentation. Other record types were not checked, and neither was the equivalent sublist on a search built through SuiteScript.