[HDX-2300] introduce Shared Filters for team-wide filter visibility and discoverability

[brandon-pereira]

Summary

Introduces a "Shared Filters" feature (in addition to locally pinned items in HyperDX.

Especially helpful for teams with lots of filters and team members, allows users to highlight the top filters easily for all members.

This has been one of the most requested features we have received from enterprise customers. \

Note: - currently any user on a team can modify shared filters - we may want/need to introduce role limits to this, but that is oos

Screenshots or video

export-1775685397652.mp4

How to test locally or on Vercel

1. Start the dev server (yarn dev)
2. Navigate to the Search page
3. Pin a filter field using the 📌 icon on any filter group header —you should be asked to pin (existing) or add to shared filters.
4. Share a specific value by hovering over a filter checkbox row and clicking the pin icon — it should also appear in Shared Filters
5. Reload the page — pins should persist (MongoDB-backed)
6. Open a second browser/incognito window with the same team — pins should be visible there too
7. Click the ⚙ gear icon next to "Filters" — toggle "Show Shared Filters" off/on
8. Click "Reset Shared Filters" in the gear popover to clear all team pins

References

• Linear Issue: https://linear.app/clickhouse/issue/HDX-2300/sailpoint-neara-global-filter-pinning
• Related PRs: Previous WIP branch brandon/shared-filters-ui (superseded by this implementation)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hyperdx-oss	Ready	Preview, Comment	Apr 10, 2026 5:54pm

[changeset-bot]

🦋 Changeset detected

Latest commit: 8ab5199

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@hyperdx/common-utils	Minor
@hyperdx/api	Minor
@hyperdx/app	Minor
@hyperdx/otel-collector	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

E2E Test Results

✅ All tests passed • 141 passed • 3 skipped • 1060s

Status	Count
✅ Passed	141
❌ Failed	0
⚠️ Flaky	0
⏭️ Skipped	3

Tests ran across 4 shards in parallel.

View full report →

[github-actions]

PR Review

Good overall implementation — source ownership verification, Zod validation, and optimistic UI with proper sourceId keying all look correct. A few things worth addressing:

• ⚠️ Stale debounce timeout on sourceId change (searchFilters.tsx) → The cleanup useEffect has [] deps, so it only fires on unmount. If the user switches sources mid-debounce, the old 300ms timer fires setOptimisticTeam(null), which clears any optimistic state the new source may have set. Add sourceId to the useEffect deps array so the timeout is cancelled on source change:

  useEffect(() => {
    return () => { /* cleanup */ };
  }, [sourceId]); // ← add sourceId

• ⚠️ unshareField E2E helper silently breaks for nested facets (FilterComponent.ts) → getByTestId(\shared-filter-group-${filterName}`)only matches non-grouped facets; nested ones get testidshared-nested-filter-group-${filterName}. The tests pass today because SeverityTextis non-nested, but the helper is a hidden trap. Consider handling both testid patterns or scoping withfilter-group-+ fallback tonested-filter-group-`.

• ⚠️ Cross-team isolation has no automated coverage → The PR comment acknowledges this (register returns 409). For a feature that writes team-wide shared state to MongoDB, consider tracking this as a follow-up test/story rather than just a code comment. At minimum, a note in the PR or a linked issue would help ensure it doesn't get forgotten.

• ℹ️ DBSearchPageFilters.tsx is now ~1800+ lines → Per AGENTS.md, files should stay under 300 lines. The renderFacetList callback alone is ~100 lines inside the component. Consider splitting this into a dedicated file (e.g. FacetList.tsx) as a follow-up.

[pulpdrew]

I see that the code includes the capability to store user-level pinned filters, but I don't see that implemented anywhere.

IMO, we shouldn't remove user-specific pinned filters, since different users are likely to care about different filter keys and values. Having no special UI for "pin for team" vs "pin for me" is likely to result in various teammates modifying the filters for the entire team without realizing they're doing so.

It's also odd that the migration from local --> team/db filters is automatic, and applies to the entire team. The first user to login after deploying this will have their filters set for the entire team, possibly unexpectedly.

I would suggest we implement both user-level and team-level filters, and have the migration create user-level pinned filters.

[brandon-pereira]

@pulpdrew you're right, I was trying to keep the scope small and minimize UX changes, but it didn't make sense.

I have changed the UX of this so that clicking the pin icons opens a menu where you can select between pin and share. I have updated the PR description with a video.

Previously localStorage was still used for local mode, but now localStorage is used for pinning and mongo is used for sharing with team.

I have also removed the migration since it's not needed.

[pulpdrew]

Makes sense, though with user-specific pinned filters always using local storage, should we remove the user field from this model now?

[github-actions]

🔴 Tier 4 — Critical

Touches auth, data models, config, tasks, OTel pipeline, ClickHouse, or CI/CD.

Why this tier:

• Large diff: 1772 lines changed (threshold: 1000)

Additional context: touches API routes or data models

Review process: Deep review from a domain expert. Synchronous walkthrough may be required.
SLA: Schedule synchronous review within 2 business days.

Stats

• Files changed: 20
• Lines changed: 1772 (+ 665 in test files, excluded from tier calculation)
• Branch: brandon/global-pinned-filters
• Author: brandon-pereira

To override this classification, remove the review/tier-4 label and apply a different review/tier-* label. Manual overrides are preserved on subsequent pushes.

[pulpdrew]

The behavior is odd for shared filters that don't load in the initial round of filters. Clicking Load More doesn't work, until clicking More filters in the non-shared section. See ScopeName here

Screen.Recording.2026-04-10.at.9.13.50.AM.mov

[pulpdrew]

I like this approach much better - just a couple more comments

[brandon-pereira]

The behavior is odd for shared filters that don't load in the initial round of filters. Clicking Load More doesn't work, until clicking More filters in the non-shared section. See ScopeName here

Screen.Recording.2026-04-10.at.9.13.50.AM.mov

Good catch - now shared filters will always be fetched on load