Skip to main content
Makes is_selected, is_filtered, and in_query template variables inside a query view resolve against the outer query instead of the view’s own query. When used inside a query view, these variables evaluate against the query view’s own inner query by default. This means they typically return "nothing selected" or "nothing filtered" once a field is wrapped in a query view, unless that field happens to be selected or filtered within the view’s own query definition. Setting bind_outer_context: true under the query: block makes these three template variables resolve against the outer query that is using the view instead. This allows fields inside query views to react to what’s selected or filtered in the outer query, rather than being limited to the view’s internal query context.

​
Limitations

  • This setting doesn’t affect materialized query views. These views will inherit this property, but cannot react to outer context since they have no outer query at execution time.
  • Querying the view directly will evaluate all template variables to false since there is no outer context to bind to.
  • Nested query views that also set bind_outer_context: true chain up to the nearest enclosing query that doesn’t itself defer. The variables resolve against that outermost query’s context.

​
Syntax

​
Properties

​
object[]
An object containing the individual parameters that make up a query view’s query definition.

​
Examples

In this query view, any field that uses is_selected, is_filtered, or in_query will evaluate those variables based on the outer query’s field list and filters, not the view’s own fields: list.
For example, if a dimension inside the users view has a sql expression that checks {% if users.email.is_selected %}, that condition will be true if users.email is selected in the outer query that references this query view, even though users.email is not in the query view’s own fields: list above.