Beyond the global search input, Browse Views support dedicated filter controls above the table — dropdowns, date pickers, toggles, range sliders. Configure them once and your users get a far better browsing experience than typing into a generic search box.
Why filters beat search
Search is universal but blunt. The user has to know what they're searching for and type it accurately. Filters are domain-specific and forgiving — a Status dropdown lists the available options so the user doesn't have to remember them; a Date Range picker constrains valid input; a toggle is binary so there's no typing involved.
For any browse view where users will return repeatedly to similar subsets of the data, filters give a much better experience than search. Add both; users will gravitate to filters once they discover them.
Adding a filter
In the Browse View's configuration, find the Filters section and click Add. For each filter specify:
- Field — which datastore column the filter narrows on.
- Display type — dropdown (single-select or multi-select), date range, search box (textual contains-match), toggle (boolean on/off), range slider (numeric min/max), pills (visual multi-select).
- Default value — what the filter is set to when the user first lands on the view.
- Label — text shown above the filter control.
- Width — pixel or percent value for the filter's horizontal space.
Stacking filters
Multiple filters are AND-combined. A user can pick a Status, a Date Range, and an Owner — and the resulting list reflects all three constraints. Filters with no selection contribute nothing (they pass everything through).
The platform's filter UI clearly shows which filters are active, with a quick "Clear all" button to reset. Active filter counts also show in the URL, so users can bookmark or share specific filtered states.
Three real-world filter sets
Example 1: Customer browse view (sales)
- Status (dropdown) — Active / Inactive / All. Default: Active.
- Owner (dropdown) — list of salespeople. Default: All.
- Total Spend Above (number) — Default: blank.
- Last Activity (date range) — Default: blank.
- Tags (multi-select pills) — Default: blank.
Example 2: Order queue for fulfilment
- Status (multi-select dropdown) — Pending / Picking / Packed / Shipped. Default: Pending+Picking.
- Required-by Date (date range) — Default: today + next 7 days.
- Warehouse (dropdown) — Default: current user's primary warehouse.
- Priority (pills) — Standard / High / Urgent.
Example 3: Ticket dashboard for support
- Status (multi-select pills) — Open / In Progress / Awaiting Customer / Resolved.
- Assignee (dropdown) — Default: "My Tickets" (current user).
- Priority (pills).
- SLA Status (toggle) — On = only show breaching SLA.
- Customer Tier (multi-select) — Bronze / Silver / Gold / Platinum.
Saved filter sets
If a particular combination is used often, users can save it as a Data Layout — see the Data Layouts section. The Data Layout captures every filter setting plus the column arrangement plus the sort order, giving the user a one-click way back to their preferred view.
Permission-respecting filters
Filter dropdowns that source their options from a datastore (e.g. a Salesperson filter listing the users group) respect the same permission rules as the rest of the platform. A user without read access to the Salespeople table sees no options in the filter — which is correct, but worth knowing when debugging "why doesn't this filter have any options for this user?".