Results table components
Use a results table to display records returned by an action or data source. It is suitable for lookups, search results, administrative lists and other structured information that people need to compare or act on.
Connect the data deliberately
Set the results-data path to the array or object returned by the relevant action. If the table is paired with a filter, both components must use the same path and compatible implementation setting.
flowchart LR
A[Action returns records] --> B[Results-data path]
B --> C[Results table]
B --> D[Optional filter]
D --> CTest with an empty result set, a single result, many results and long values before adding pagination or exports.
Design for scanability
Use short, specific column headings and show only information needed to identify or act on a record. Put the most important column first. Avoid dense tables with many narrative columns; link to a detail view instead.
Choose features deliberately: result counts, pagination, sortable columns, scrolling, row-count selection, export or bulk edit. Built-in sorting is not compatible with pagination; use a paired filter component for sorting paginated results.
Pagination and export
Choose whether pagination happens in the interface or through the data action. For action-based pagination, provide the total row count through the configured template so people can understand the result set.
Enable exports only when people are authorised to take the data out of the service. Test full-result and current-page exports separately, including filename, format, encoding, long values and sensitive fields. A visible export control is not an access-control mechanism.
Provide a useful empty and error state
Results can legitimately be empty. Explain what “no results” means and what the person can do next, such as changing a filter, checking a reference or contacting a team. Do not present an empty table as though the search succeeded but found nothing when the underlying action has failed.
Where a table depends on an action, distinguish a no-match result from an unavailable data source. Design the condition or content that handles each state, and test the action failure path in QA.
Design row actions carefully
If rows include links, buttons or bulk actions, make the purpose clear from the row context. Use descriptive text that includes the relevant record identifier where necessary. Do not rely only on the position of a button in the table.
For bulk edit or export, confirm who is allowed to use the feature and what happens to selected rows when filtering, sorting or moving to another page of results. A results table should help people make a controlled decision, not conceal a large operation behind an ambiguous control.
Test checklist
- The data path returns the intended structure for empty, single and multiple results.
- Headings and column order support the user’s decision.
- Empty, no-match and action-failure states are distinct and understandable.
- Pagination, filtering and sorting work together as designed.
- Row actions work with keyboard navigation and a narrow display.
- Export and bulk actions are limited to authorised users and tested with sensitive fields.