Solved

Dashboard filters tied to multiple fields in same look


Is it possible to tie a dashboard filter to multiple fields in the same look? I have two sets of similar data in the same look and would like to be able to filter both sets with one filter.

icon

Best answer by lloydtabb 6 September 2017, 22:44

You could make a filter that filters both conditions. Filters with sql clauses get put in the WHERE clause of the main query. You would then have a single filter you could bind the dashboard to.



Does this help?



filter: employee_and_customer_location {

sql:

{% condition employee.location %} ${employee.location} {% endcondition %}

AND

{% condition employee.location %} ${customer.location} {% endcondition %}

;;

View original

13 replies

Userlevel 3

@Brian_Winkle,


Is this to create a filter that is a predicate that is dim1 = “string_value” OR dim2 =“string_value”?

Say I have dashboard that includes a table that contains my number of both customers and employees over time. I’d like to, for instance, be able to filter both the customers’ and employees’ locations at the same time using the same filter.

Userlevel 3

Are the customers’ and employees’ locations on separate fields?


Currently our regular filters generate AND statements for the predicate. If we had a way to bind the filter against multiple fields, it would ultimately be customer.location = “string_value” AND employee.location = “string_value”


I’m trying to figure out what kind underlying data and desired SQL is needed like with an OR clause. I think this may be something I’ll have to pass along to product.


There’s also ways of making the columns shared via a PDT by COALESCING those columns together and generating a table where entities share the same columns.

Hi @mikhailxu,


I am just wondering if there has been an update to answer this problem? I may have a similar situation.


Thanks,


Kieran

Userlevel 6
Badge

You could make a filter that filters both conditions. Filters with sql clauses get put in the WHERE clause of the main query. You would then have a single filter you could bind the dashboard to.


Does this help?


filter: employee_and_customer_location {
sql:
{% condition employee.location %} ${employee.location} {% endcondition %}
AND
{% condition employee.location %} ${customer.location} {% endcondition %}
;;

Yes!


Great thanks

Dredging this old one up. 🙂


I hit the issue where I have a dashboard tile that has two different time dimensions. In this case, I’d like for the query to accept a single time-filter input from the end user via a dashboard, but apply the logic identically to both independent time dimensions in the underlying query.


In many cases, this can be achieved with a dimension like the one @lloydtabb proposes. However, there are a lot of potential combinations in this explore where two or more time dimensions need to be coupled together. In my mind, creating additional dimensions for all of the combinations adds to model bloat. For our specific case, one field that could potentially “listen” for this filter is a dimension, this other, however, is a filter-only field that makes its way into a derived table via a templated filter. So it’s kinda complicated.


From the look of it, these dashboard filters really seem like general inputs that could be routed to different dimensions in a query in a one-to-many fashion. Why are with locked into a one-to-one world here?

Thanks a bunch. This helped me.

Same issue here.

The solution above creates model bloat.


Would be easily fixed if the dashboard filters can be mapped two 2 fields.

Super easy to add as well.

Agreed. Dashboard filters should allow a 1-to-many mapping: 1 filter value or field to 1 or more (any number of) other fields. This is definitely a shortcoming of Looker. I have this problem too.

Userlevel 1

@Michael are there any updates on the issue of a dashboard filter being able to link to more than 1 field?

I too am wondering if this functionality of a dashboard filter being able to link to more than 1 field is available yet?

I found this:

might work for this use case, I’m going to test this out

Reply