Skip to main content

​
Discovery & Search

The Explore page is redesigned in 2.0, and the redesign is shared by both Classic Mode and AI Mode. The mental model changes from “the tree replaces your filters” to “the tree sets a browse location that stacks with your filters.” Filtering, browsing, pagination, ranking, and export all behave differently.

​
Explore URL parameters changed

Breaking. Affects bookmarks, saved links, embedded iframes, and anything that constructs Explore URLs. A 1.13 link with ?page=3&size=25 still loads Explore, but silently lands on page 1 at the default page size — no error and no redirect. The route itself (/explore/:tab) is unchanged. Explore also now accepts only 15, 25 or 50 rows per page; any other pageSize, including one inherited from a user’s stored global setting, is coerced back to 15.
Update deep links, embedded dashboards and internal documentation to currentPage/pageSize.

​
Browsing no longer clears your filters, and facets are scoped differently

Behavioural. Affects every Explore user. In 1.13 the left tree drove the quick filters directly — selecting a service overwrote the filter state. In 2.0 the tree writes to its own browsePath parameter, compiled into a separate search filter and AND-ed with the dropdown filters. Selecting Tier 1 and then browsing to a schema now keeps the Tier 1 filter; removing a browse chip truncates the path from that level down. Facet aggregation also changes: in 1.13 every dropdown’s aggregation was computed against the full combined filter including that dropdown’s own selection, so selecting “Table” in Data Assets shrank the Data Assets dropdown to just “Table.” 2.0 excludes a facet’s own field from its own aggregation — within one facet, values are OR-ed and the option list keeps showing alternatives; across facets, constraints are AND-ed.
UI tests that clicked Update to commit a dropdown selection must drop that step — selections apply immediately in 2.0. The “Clear all” text link is removed, replaced by Clear All on a new query chip row; test suites keyed on data-testid="clear-filters" must move to data-testid="explore-query-filter-chips". Note also that dismissing an Advanced Search query no longer resets quick filters and browse location — it only clears the advanced query.

​
Result ordering changes

Behavioural. Affects every search and Explore result list. Search settings gain a per-asset-type ranking block: ordered lexical stages first (name matches outrank description and context matches), then bounded metadata signals (Tier, usage) capped at maxBoost: 2.0 so they act as tie-breakers rather than dominating relevance. The 2.0.0 migration writes this default configuration into any existing stored search settings, merging in missing stages rather than overwriting operator customizations.
Expect different result ordering after the upgrade: same query, same corpus, different order. If you have automated tests asserting the top result for a given query, re-baseline them. Tune the behaviour under Settings > Search > Ranking, which gains a Reset to Default button in 2.0.
The search_after cursor-paging parameter also changes shape — see API & Schema.

​
CSV export becomes a background job

Behavioural. Affects Explore users exporting search results. Choosing Tools > Export no longer downloads a file directly. It queues a background job (jobType: CSV_EXPORT), shown in a new Background jobs tray, and is downloaded from GET /v1/csvAsyncJobs/{jobId}/result. Exporting “all” now covers the full tab result set with an accurate pre-count, capped at 200,000 rows.
The synchronous endpoint still exists — GET /v1/search/export is unchanged and still streams CSV directly. Only the UI switched to the async endpoint, so scripted exporters don’t need to change.

​
Explore result caching and tree count semantics

Behavioural, low risk but worth knowing about. 2.0 adds a short-lived stale-while-revalidate cache keyed by the full search dependency string: a cache hit renders synchronously with no spinner, then a background refetch updates it. A stale-response guard drops in-flight responses whose key no longer matches the current search, so a slow response can no longer overwrite a newer result set. UI tests that wait for a loading spinner on tab switch need to key off content instead. Tree counts also now aggregate over the whole data-asset index at every level — a node’s count is the total matching objects in its subtree, respecting active filters and browse path — where 1.13 counted only the immediate children from the per-entity index.

​
Full detail

For the full narrative walkthrough of Discovery & Search in Collate 2.0 — including screenshots and step-by-step context — see Release 2.0: Discovery & Search.