The quick answer
Use the same request parameter name in the client URL and the Suitelet. Read the selected primitive internal ID, add the item criterion to a fresh search while preserving its base criteria, and set the select’s default value when rebuilding the form. An empty selection should omit only the dynamic item criterion.
This walkthrough executes supplied JavaScript in bounded local serverWidget, search, currentRecord and location stand-ins. A reusable NetSuite-like form renders the computed descriptor. Its local route update models a fresh GET; it does not prove native asynchronous grid refresh, deployment, permissions or client-module loading. The original forum thread has no accepted working resolution. This example isolates its mismatched parameter names rather than claim to resolve the full original script.
Before you start
The representative Transactions form has an Item select and a Results LIST sublist. It is filter-only, with no unsaved transaction edits. The local input contains three invoice lines: INV8821 and INV8822 for Pressure Manifold, internal ID 1452, and INV8823 for Valve Housing, ID 1453. A sales-order line is excluded by the fixed invoice criterion. Person and operating-company names are fictional example data.
The supplied server source already uses the documented form.clientScriptModulePath property, primitive item IDs, ANYOF, preserved base filters and the select’s defaultValue. The client exports pageInit and fieldChanged. Those are prerequisites in this reduced example, not fixes performed during the walkthrough. The server source is available through the workbench’s View transaction_filter_suitelet.js link.
01. Inspect the baseline
Open the representative form. All Items is selected, and the list contains all three invoice rows. The local server loads a fresh search with type=CustInvc and mainline=F. There is no item criterion. The fixture supplies input records; the displayed results are computed by the executed source.
02. Trace the mismatched parameter
Choose Pressure Manifold. The reduced client sends filer=1452, while the server reads custpage_item_filter. The expected key is absent, so the rebuilt form returns to All Items and still contains three baseline rows.
Open the Suitelet Filter Workbench and inspect the last local GET request. The trace shows the wrong key, the absent expected parameter, no item criterion and Computed rows: 3. This is a missing-key demonstration, not a policy of accepting invalid requested IDs.
03. Use the expected key
In filter_client.js, change both 'filer' literals to 'custpage_item_filter'. Keep the body-field guard on custpage_item: the field ID and request parameter name intentionally differ. The handler reads the selected primitive ID, uses URLSearchParams.set to replace the parameter, and delete for the empty option. Other routing and view parameters survive.
The handler does not edit the LIST sublist DOM or disable navigation warnings. The local adapter executes the source and follows its computed navigation target. Native client execution and browser navigation behavior require separate account verification.
04. Rerun and restore the selection
Click Save and wait for its saved acknowledgement. Reopen the clean initial local Suitelet URL and choose Pressure Manifold again. This creates a new modeled GET with custpage_item_filter=1452. The supplied server validates the known fixture ID, adds its item ANYOF criterion and computes two rows without saving the search.
The rebuilt form retains Pressure Manifold because the server assigns the select’s default value. Only INV8821 and INV8822 remain.
Return to the workbench. The actual local request trace now shows ID 1452, the applied item criterion and Computed rows: 2. The fixed invoice and non-mainline criteria remain. The workbench is a local execution aid, not a NetSuite execution log.
05. Switch and clear
Return to the filtered form and select Valve Housing. The parameter is replaced with 1453, rather than appended, and only INV8823 remains.
Choose All Items. The client omits custpage_item_filter; the server omits only that item criterion. The three baseline invoice rows return. Script, deployment and view=compact remain in the local URL. The original search definition stays unchanged throughout the exercise.
The success check is 3 → 2 → 1 → 3 computed rows, with the selected option restored after each modeled GET. After reopening the clean URL and selecting an item, exactly one custpage_item_filter is present and the old filer key is absent. Malformed, unknown and duplicate item parameters are separately tested: the local HTTP adapter rejects them with 422. That status and two-ID fixture allowlist are local conventions, not verified native authorization or response behavior. The model does not silently broaden invalid requests to all items.
Common questions
Why does my Suitelet select reset after fieldChanged?
Check the actual parameter key and value reaching the server. Then assign the selected value to the rebuilt field’s defaultValue. In this exercise, the wrong key leaves the expected value absent; the fixed key reaches the server and is restored. Native deployment and other script defects can cause different failures.
Should the field ID and URL parameter name match?
They may differ. Here the body field is custpage_item, while the request key is custpage_item_filter. Guard fieldChanged with the actual body field ID and use the request key consistently on both sides of the navigation.
Can I pass the serverWidget Field object into a search filter?
Use the selected primitive internal ID. The original source passes a Field object in one filter expression; that is outside this reduced typo repair. A display name or field object is not the selected internal ID.
Does fieldChanged run for a value supplied in the URL?
Oracle documents that URL-supplied values do not trigger fieldChanged. In this design, the server reads the request and sets the default while rebuilding the form; the next manual selection triggers the client handler.
Can I use this with unsaved transaction edits or large result sets?
Those cases were not tested. This form is filter-only and the fixture is small. Assess unsaved-data handling, result limits, paging, search permissions and account-specific client loading separately. Do not globally suppress navigation warnings to make a redirect appear successful.
Why might the select still reset after fixing the key?
Verify that the intended client file is loaded and exports the handler, that its guard uses the body field ID, that the URL sends the expected key once, and that the server assigns the primitive ID to defaultValue. The selected option must exist in the rebuilt select. Those account checks remain outside this local exercise.
Is the local allowlist a production authorization design?
No. It permits only two known fixture IDs and rejects invalid input. A deployed endpoint needs its own verified authorization and validation design; this local model does not establish one.
Supporting documentation: Form.clientScriptModulePath, Field.defaultValue, fieldChanged, and the source discussion.