Oct 6, 2026/7 min readCore Platform
Rebuilding Observe's Filter Bar: Full Query Language, Same Autocomplete
When an incident starts, engineers rarely begin with a perfectly formed query. They might have an alert, a log line copied from a ticket, or a vague description of what seems broken. In Observe by Snowflake, the filter bar (an input where users enter filters for the data they’re viewing) is often the first place they turn that context into an investigation.
Learn more about Observe by Snowflake and how it turns telemetry into insights — fast
The original filter bar was a useful and familiar way for many Observe users to explore their data. Over the years, customer feedback and our own experience using Observe helped us understand how it could better support users, leading us to build a new filter bar informed by what we learned and designed for the use cases we wanted to support next.
The new filter bar (private preview) gives users more control over that investigation. It combines the familiar expression builder with the flexibility of OPAL, Observe’s query language for filtering and transforming data, so users can build a simple field-and-value filter or compose a more advanced filter statement without leaving the expression builder. This lets power users build queries faster while helping users less familiar with Observe create queries independently.
Old version of the filter bar, containing an individual filter:
New version of the filter bar that takes an OPAL query rather than individual filters:
To build the new filter bar, we built a new version of OPAL with more human-readable filter syntax that lets our filter statements behave as users expect.
With the new filter bar experience, users can:
- Express complex boolean logic directly in the filter bar
- Introduce OPAL functions into their filters
- Continue using autocomplete for fields, values and JSON paths
- Continue keeping filters synchronized across the filter bar and other parts of the Observe interface
Below we summarize why we rebuilt the filter bar, what’s changed for users and how the new implementation preserves existing product features.
What our filter bar did well and the improvements we made
The original filter bar represented each filter as a visual “pill.” Users entered one pill at a time by typing or selecting a suggestion from autocomplete. Each pill followed a familiar structure: field, operator and value. For example, this pill is how a user would look for rows with a duration column with a value greater than 1 second:
duration > 1s
This method worked well for simple filters. Users often found it easy to write filters using this component, as the syntax was simple and the autocomplete was powerful. Pasting a value into the autocomplete suggested the fields that value was present in; it also loaded more values if you weren’t sure what you were looking for.
The old filter bar autocomplete.
As investigations required more expressive logic, users needed capabilities the pill model wasn’t designed for.
The original filter bar used a fixed filter-combination strategy. Equality filters on the same field were grouped with OR (a field cannot match two values at once), while those “OR groups” and other filters were combined with AND. For example:
(stream = "stderr" OR stream = null) AND body ~ "error"This behavior covered most common and simple cases, but wasn’t designed for more complex use cases. The pill model was designed for simple field-value filters, not arbitrary grouping or boolean expressions. For queries that needed custom grouping or boolean logic, users moved to the OPAL console — a more powerful environment, but one that left behind the filter bar’s autocomplete and the rest of the expression builder.
The pill representation also introduced a second challenge: It didn’t always match the OPAL query that it generated. The OPAL syntax that the filter bar generated didn’t always match what users entered, which sometimes led to unexpected results or compilation errors.
Here is a comparison of filters users could enter in the bar and the OPAL that those filters generated.
| Filter bar expression | Generated OPAL | Reason |
|---|---|---|
| field != "value" | filter is_null(field) OR (field != "value") | OPAL uses three-valued logic. |
| field = $multiSelectParameter | filter array_contains($multiSelectParameter, field) | A multi-select parameter is represented as an array value. |
These translations were correct for execution, but inconsistent syntax made the relationship between what users entered and what OPAL ran less clear.
The new OPAL version with simpler syntax and predictable results
Improving filter evaluation in OPAL required changes to how certain operators behaved, so we introduced OPAL versions to let us evolve the language without disrupting existing context. We decided to introduce OPAL versions (prior to this change, Observe had one version of OPAL) and put some of these changes behind the new version to accomplish that.
To support this, we created a new version of the OPAL language to make it more ergonomic for filtering, adding support for common filters such as parameters so entering a familiar field-operator-value filter produces results as it did in the old filter bar.
When you open old objects in Observe, we automatically upgrade the content and version to support these changes. This appears in the header, with the option to revert if needed.
A dashboard automatically upgraded to a new OPAL version.
The filter bar now accepts a complete OPAL statement
The new filter bar changes the underlying model. Instead of representing a filter as a collection of independent pills, it accepts a complete OPAL statement that is preceded by a filter verb under the hood.
A simple expression, such as the duration filter described above, still feels familiar:
duration > 1s
That same filter is entered as the same piece of text.
With these changes, users can now extend that expression when the investigation requires it. They can combine boolean logic, call functions and use the broader capabilities of OPAL without leaving the page or losing the expression builder’s context.
For example, a user can express a filter with boolean combinations previously not possible in the filter bar, such as the one here:
(stream = "stderr" OR body ~ "error") AND cluster = "k8s.my.cluster"Users can also enter OPAL functions, enabling an even wider range of filters by transforming the data they are viewing in the table.
This approach expands the filter bar without forcing every user to start with a complex query. Simple filters remain simple, while advanced users gain a direct path to more expressive investigations.
Autocomplete that supports the full expression
The new filter bar would be less useful without guidance while users write. We expanded the OPAL autocomplete to match the capabilities of the old filter bar’s autocomplete. It includes suggestions for fields, values, functions and JSON paths based on the current input and page context.
The filter bar’s new autocomplete filling in a filter for a value present in the data.
The result balances flexibility and discoverability. Users can write a complete expression when they know what they want, or use suggestions to discover available fields and functions as they build the filter.
Keeping the interface synchronized
The filter bar is not the only way to add a filter in Observe. Users can also filter through the side rail and the table’s context menus. The new filter bar keeps all of these entry points synchronized. Edit a filter in the bar and it updates across the interface; add one from the side rail and it appears in the expression. No matter where you start, the filter bar stays the source of truth.
The side rail and the filter bar synced up.
What this means for Observe users
The new filter bar brings OPAL’s flexibility closer to where investigations begin. Users no longer need to choose between a guided filter builder and a powerful query language for every investigation.
They can start with a familiar field-and-value expression, use autocomplete to explore available options and add more complex logic as needed. At the same time, filters created through other parts of the interface continue to appear in the filter bar, so users can switch between interaction styles without starting over.
Get started with the new filter bar
The new filter bar is available for private preview in Observe by Snowflake. Open an Observe exploration and enter a filter expression in the filter bar, or add a filter through the side rail and see it reflected in the expression.
To learn more about Observe by Snowflake, visit the Observe product page.
