Filter components
Use a filter component with a results table when people need to narrow or sort a set of returned records. The filter and results table must refer to the same results-data path and use compatible implementations.
Connect the filter to the right results
Start by identifying the array of results returned by the relevant action or held in the journey context. Configure that same path in the filter and its paired results table.
flowchart LR
A[Action or data source returns records] --> B[Results-data path]
B --> C[Filter component]
B --> D[Results table component]
C --> E[Filtered and sorted records]
D --> EIf the paths or implementation types differ, the interface may appear but not filter the intended results. Test with a known result set before adding complex categories.
Choose filtering and sorting behaviour
For smaller result sets, the service can filter and sort in the interface. For larger or sensitive data sets, a backend action can apply the criteria instead. Match this choice in the results table and test performance with a realistic number of records.
Use only filter categories that people can understand: a short keyword input, a known-choice list, a date range or a number range. Label each category with the property it filters, and use hint text for formats or boundaries.
Sort options should describe the ordering outcome, such as “Date: newest first” or “Name: A to Z”. Choose alphabetic, numeric or date sorting to match the underlying data type.
Make filters easy to use
Keep the sidebar narrow enough that results remain readable. Reveal sort controls only where it meaningfully reduces clutter; do not hide a core control that most people need.
Test empty results, no selected filters, each category alone, multiple categories together, clearing or changing a filter, every sort option, a long result value and keyboard navigation.
Do not expose filter values or result fields that a person is not authorised to see. Filtering affects presentation, not access control.