Does wrapping a saved search formula in NVL fix the null rows in a CASE WHEN?

No. Both formulas were run and grouped against the same data, and the two outputs were identical in every bucket, to the row. Zero rows moved.

This is worth stating flatly, because "wrap it in NVL" is the standard answer on every forum thread about nulls in a saved search formula, and against a CASE shaped like the one below it does nothing at all.

Minimal reproduction

Two Results columns, run as a grouped search. Column one is the formula under test, column two is a Formula(Numeric) containing the literal 1 with its summary set to Sum, which is the only reliable way to count rows in a saved search.

Raw:

Formula(Text) = CASE WHEN {quantity} > 1000 THEN 'large'
                     WHEN {quantity} > 0    THEN 'small'
                     ELSE 'other' END                        [Group]
Formula(Numeric) = 1                                         [Sum]

Wrapped in NVL:

Formula(Text) = CASE WHEN NVL({quantity},0) > 1000 THEN 'large'
                     WHEN NVL({quantity},0) > 0    THEN 'small'
                     ELSE 'other' END                        [Group]
Formula(Numeric) = 1                                         [Sum]

Three buckets came back from each run, and all three totals matched between the two runs exactly. Not approximately. The same numbers.

Why nothing moved

NVL({quantity},0) turns null into 0. Zero fails > 1000 and it also fails > 0, so the row falls through both WHEN branches and lands in ELSE, which is precisely where it already was. All NVL did was move a row from "null, therefore ELSE" to "zero, therefore ELSE".

The reason the raw version put nulls in ELSE in the first place is that NULL > 1000 and NULL > 0 are both UNKNOWN in SQL, not false, and a WHEN only fires on true. A null row therefore falls through every branch you write and lands in whatever you left at the bottom. It does not error. There is no null marker anywhere in the output.

The bucket that hides three populations

The bigger problem is the one the NVL question distracts from.

That ELSE bucket is not one thing. It fuses rows where the value is null, rows where it is genuinely zero, and rows where it is negative, and it reports them under a single label. A reader of the report sees one category called other and has no way to tell what it is made of.

In the account tested the split was badly lopsided: nulls were the overwhelming majority of that bucket, on the order of 98 per cent of it as a proportion, with real zeros and real negatives sharing the small remainder. That figure is rounded, and it is a proportion of one bucket in one account rather than something to expect elsewhere. The shape is what matters. A bucket labelled as a business outcome was almost entirely missing data, and the report said nothing.

Two details from the run are worth borrowing. First, the three bucket totals reconciled exactly against the null, zero and negative populations counted separately, so the composition is measured rather than inferred. Second, the field originally chosen for this probe turned out never to be null in that account, which is its own lesson: if you are testing null handling, confirm the field actually has nulls before concluding your formula handles them.

The fix

Branch on the substituted value, and put that branch first:

Formula(Text) = CASE WHEN NVL({quantity},-1) = -1 THEN 'missing'
                     WHEN {quantity} > 1000       THEN 'large'
                     WHEN {quantity} > 0          THEN 'small'
                     ELSE 'other' END

Now NVL is doing work, because something in the formula tests for the substituted value. Pick a sentinel the data cannot produce; -1 is only safe on a field that is never legitimately -1, and on a quantity field it may not be. IS NULL is the alternative and avoids the question entirely.

The rule this generalises to: NVL is not a null-handling strategy, it is a substitution. If nothing downstream of it branches differently because of the substitution, wrapping the comparison changes nothing.

How to tell if you are affected

Add a WHEN {yourfield} IS NULL THEN 'missing' branch as the first branch of any existing CASE, run it grouped with a Sum-of-1 column, and compare the new bucket against your old ELSE. If most of ELSE moves into missing, every report built on that formula has been presenting absent data as a business category.

Scope: one sandbox account on NetSuite 2026.1, Administrator role, one numeric field on the transaction record. Both searches were built and run ad hoc through the SuiteScript search engine (nlapiCreateSearch / runSearch) without saving anything, and the comparison is between two runs against the same data.