Filtering

• Reference
• 6 minutes

Strato provides a variety of filter components, compositions, and best practices to help users efficiently filter and find information in tables, charts, lists, or entire apps.

Getting started

Consider these questions before you select filter components or design a filtering experience:

• How complex is the dataset or object group that needs filtering? Are there dozens of potential filter categories and combinations or just a few?

• Which questions will target users have about the data? In which order might they have these questions? How might their workflow with the dataset look?

• How technical are the target users? Are they accustomed to building queries with Dynatrace Query Language (DQL) or another query syntax?

The next section describes which filter components to use for different user and data scenarios. See Best practices for tips on layout, behavior, and accessibility.

Filter scenarios and solutions

Filter scenario	Main component or pattern	Combine with
Filter large, complex datasets with many properties using AND/OR operators and query syntax.	FilterField	Optional: SegmentSelector, TimeframeSelector
Filter simpler datasets with few properties using different methods (text input, single or multiple selection, etc).	FilterBar	Optional: SegmentSelector, TimeframeSelector
Select a segment as the scope for additional filters or queries.	SegmentSelector	Optional: Any filter component
Filter by preset or custom timeframes.	TimeframeSelector	Optional: Any filter component
Select a particular cell within a data table to trigger filter actions.	In-context filtering within data tables	Required: DataTableV2, TableActionsMenu, FilterField
See dynamically updated timeframe data while zooming in or out of a chart.	In-context filtering within charts	Required: TimeframeSelector, ChartInteractions.Zoom, ChartInteractions.Tooltip

Component overview

Choose the simplest filter component or combination that meets users' filtering needs.

FilterField

Description: An advanced filtering component that supports complex filtering using Filter field syntax, plus auto-suggestions. See Usage.

Best for:

• Large datasets with more than five filter categories and several operators
• Power users accustomed to building queries
• Users with highly individual filtering needs
• Scenarios requiring OR operations

Note

DQLEditor may be used instead of FilterField in special cases where users need to combine advanced filtering with editing DQL queries.

FilterBar

Description: A versatile filtering component that supports a variety of filter methods, including text input, single or multiple selection, booleans, and more, based on form components. See Usage.

Best for:

• Tables or lists with five or fewer filter categories
• Scenarios requiring a few simultaneous filters and no query-building skills
• Cases where filter categories should be visible and simple to use
• Situations requiring different types of filters, such as selection, text input, timeframe, etc. (Note: TimeframeSelector provides the functionality for filtering by time.)

SegmentSelector

Description: Component for filtering data by pre-defined Segments (applications, infrastructure, organizational units, etc.). Functions as a top-level filter, setting the scope for additional filters. See Usage.

Best for:

• Top-level filtering that sets the scope for additional filters

TimeframeSelector

Description: Component for filtering data from specific timeframes. See Usage.

Best for:

• Scoping data by time
• Historical data analysis
• Time-filtering functionality in FilterBar

Form components

Description: Form components provide filter logics for FilterBar and can also be used as standalone filters:

• Single selection - Radio, Checkbox, or SelectV2
• Multiple selection - Checkbox or SelectV2
• Boolean - Switch
• Date/time picker - DateTimePicker
• Text - TextInput

Best for:

• Filter logics in FilterBar
• Standalone filters for simple datasets or lists
• Filters in the sidebar, used in combination with FilterField

In-context filtering

Give users the ability to filter directly from the data context (table, chart, list) without needing to switch views, copy-paste, or type values elsewhere. Here are a couple examples:

Within data tables

Let users trigger different filter actions simply by selecting a cell. The selected filter action should appear with valid syntax in a FilterField above the table. To implement, see DataTableV2 Configure cell actions.

Within charts

As users zoom in or out of areas of charts with timeframe or numeric data, show the dynamically updated timeframe data in the tooltip and the TimeframeSelector above the chart. To implement, see TimeseriesChart ChartInteractions.

Best practices

Layout

Follow these established Dynatrace filter patterns to maintain consistency and predictability:

• Position filter groups directly above or beside their affected data.
• Group related filters together.
• Arrange filters from general to specific:

1. Start with SegmentSelector (top left).
2. Enable category filters with Filter or FilterField, not both.
3. Place TimeframeSelector at the end.
4. Place additional action buttons or menus on the right side of the filter group.

Note about filters in the sidebar

If your app doesn't need FilterField, and there are five or fewer filter categories, don't put filters in the sidebar. Use FilterBar instead.

In rare cases, a combination of FilterField plus a few form component filters in the sidebar may improve filtering experiences by helping users discover which filters exist. In these rare cases:

• Form components in the sidebar should always be combined with FilterField as the primary filter.
• Only put the most important filters in the sidebar. There should never be as many filters in the sidebar as there are filter categories. All filter categories are accessible with FilterField.
• The user's selections in the sidebar should be visible in FilterField with correct syntax. Likewise, filter statements in FilterField should be visible in any corresponding filter in the sidebar.
• Use Accordion to enable collapsing filters in the sidebar. The first accordion should be open in the starting state.

Behavior

Starting state

• Start with all selected if most users will eliminate one or a few values.
• Start with all unselected if most users will select just one or a few values.

State persistence

• Users may need to navigate away from a filtered view during a flow. Their filter selections should persist until they reset their filters, refresh the page, or the session times out.

Validation messages

• If there are no results to a user’s filter selection, provide a "No results found" message with suggestions to adjust the filters.

Dynamic vs batch filtering

Use dynamic filtering (immediate update) for

• Single filter controls with instant results
• Text inputs, selects, and valid syntax queries (FilterField)
• Applications that respond quickly

Use batch filtering (delayed update) when

• Multiple filter selections are needed for meaningful results
• Processing time is required
• Dynamic filtering could incur extra costs for the user or Dynatrace
• You’re unsure – batch filtering is the safer choice to avoid premature updates that might frustrate users

Sharable filter views

• Enable users to share filter views. Recipients should see the filtered view that was shared, without the need to manually apply filters.

Accessibility

• Use labels that can be understood by most users.
• Provide clear, actionable error messages that help users resolve issues independently, if possible.

Related

Components

• Checkbox
• Radio
• Switch
• SelectV2
• TextInput

Documentation

• Filter field
• Filtering and sorting
• Segments