The quick answer
Create fresh search.Column objects with the desired sort. Reusing a column preserves the sort set when it was created. Build an unsaved runtime search with the new sort precedence, retain the intended filters and use a unique ordering before runPaged.
This walkthrough executes a SuiteScript 2.1 helper against an explicit local N/search mock. It demonstrates a limited plain Item search, computed paged results and an actual local CSV. The mock ignores assignments to existing Column.sort; that models the documented contract, rather than capturing a native exception or executing an account search. The native-style list establishes local search identity only.
Before you start
The fixture is Items by Name, script ID customsearch_items_by_name, with an original itemid ASC order and isinactive is F filter. Seven items match. An eighth inactive item has quantity 100 and must remain excluded.
The helper accepts one row per Item and three plain columns: itemid, quantityavailable and internalid. It rejects joined, summary, formula and special-function columns, as well as ambiguous duplicate target columns. It is not a universal saved-search cloner. Adaptation requires an appropriate SuiteScript context and account-specific search permissions, item visibility, features and field support.
01. Identify the source search
Locate Items by Name, customsearch_items_by_name, type Item, in the local Saved Searches list. The ID column here contains a script ID. The checked-in fixture defines the original sort and filters; the list does not show or verify native Item result settings.
02. Check the original ordering
The deliberate first command assigns undefined to the existing Name column sort and DESC to the existing Quantity column sort. The local output labels those writes as attempted assignments and reads back the actual retained values: Name ASC and Quantity unset. The model keeps the original itemid ASC ordering. Oracle documents that a column's sort cannot be changed after creation. Oracle: Column.sort
Open the local viewer's second page. It still contains Fir 7 and Grove 3, while the original first page contains quantities 2, 9, 4, 9, 1. Reordering only those five visible rows would leave the later quantity-7 row on the wrong page.
The ignored assignment is explicit mock behavior. Do not rely on a particular native exception or error message.
03. Create fresh sort columns
Construct a fresh quantityavailable DESC column first and internalid ASC second. Recreate the remaining Name column without a sort, so its old ASC metadata does not take precedence. The helper preserves the plain column names and labels. Oracle: search.createColumn
const columns = [
search.createColumn({
name: 'quantityavailable',
sort: search.Sort.DESC
}),
search.createColumn({
name: 'internalid',
sort: search.Sort.ASC
}),
search.createColumn({
name: 'itemid'
})
];
Pass the loaded type and filter expression into a new search. The checked-in helper also copies labels and settings; this fixture's settings array is empty.
const options = {
type: base.searchType,
filters: base.filterExpression,
columns
};
if (base.settings) {
options.settings = base.settings;
}
const runtime = search.create(options);
search.create accepts a filter expression through filters. This creates an unsaved runtime search, rather than changing the source saved definition. Oracle: search.create
The local proof reports fresh column objects, the new precedence, preserved filters/settings, seven rows, two pages, 131 CSV bytes and zero Search.save calls.
04. Inspect the globally sorted first page
The helper defines the search ordering before paging with a page size of five. Oracle requires a unique, unambiguous sorting order with specified precedence for runPaged. Supported page sizes are 5 through 1000. Oracle: Search.runPaged
The computed first page contains Birch 9, Drift 9, Fir 7, Cedar 4 and Grove 3. IDs 8102 then 8104 resolve the quantity-9 tie. Fir moves from the original second page into the new first page, demonstrating a sort across page boundaries.
This viewer displays identity columns in a convenient table order. That display order is separate from the runtime search's sort precedence.
05. Verify the full result
The second page contains Aster 2 and Elm 1. Across both pages the sequence is 9, 9, 7, 4, 3 | 2, 1, with all seven matching IDs appearing once. Inactive item 8108, quantity 100, remains excluded by the preserved filter.
Download sorted_items.csv. The capture compares its bytes exactly with the local file: 131 UTF-8 bytes, including the actual headers and line endings. This is local serialization proof, rather than native export behavior. The original fixture remains itemid ASC, and no account query or Search.save occurs.
Common questions
Why recreate columns that are already available?
The original column objects carry their creation-time sort. Fresh copies prevent the old Name ASC ordering from surviving. Preserve the properties your actual search needs; this helper deliberately rejects complex columns instead of silently losing their semantics.
Can I load a saved search without changing it?
Yes. Use the loaded definition as input to a separate in-memory search and avoid saving the source. The example models this distinction locally; it does not load or modify a search in an account.
Why sort before paging?
Sorting only the visible page cannot move Fir 7 from the old second page into the first page. Define the search-level ordering first, then use runPaged and fetch to traverse it.
Is internalid always a sufficient tie-breaker?
It is unique for this one-row-per-item fixture. Joined, transaction-line or grouped results can contain multiple rows per internal ID. Choose keys that uniquely identify the actual result grain and preserve the required precedence.
Are real paged results a snapshot?
Oracle documents that they are not cached. Concurrent additions, edits or deletions can change results during traversal. The static local fixture does not prove a snapshot, stable traversal under concurrent changes or a native page-sort control.
Does this helper handle blank quantities?
The fixture contains only numeric, nonblank quantities. It does not normalize blanks or establish native null ordering. Define and verify the desired blank-value behavior when adapting the search.
Can this clone every saved search?
No. Joins, formulas, summaries, functions, duplicate target columns, search-specific attributes and permissions require additional handling. The helper rejects these cases. Preserve the intended filters, settings, column attributes and row grain when building a broader implementation.