Grouping Fields Within Views (3.44+)

(Brett Sauve) #1

Some users have wanted greater control over how fields are grouped in Looker’s field picker. Looker 3.44 adds the new group_label parameter to let you group fields together, even within the same view.

Existing Things You Could Already Do

Since 3.20 it’s been possible to adjust the first level of grouping (aka you can adjust the views) by using the view_label parameter.

type: time dimension groups have also automatically grouped together within each view for quite a while:

New Things You Can Do in 3.44

As of 3.44, you can control how the fields are grouped within each view by using the new group_label parameter. For example, you could create a group of shipping fields that would look like this:

You would achieve this with the following LookML:

Old LookML ``` - dimension: shipping_city sql: ${TABLE}.shipping_city group_label: 'Shipping Info'
  • dimension: shipping_state
    sql: ${TABLE}.shipping_state
    group_label: ‘Shipping Info’

  • dimension: shipping_street
    sql: ${TABLE}.shipping_street
    group_label: ‘Shipping Info’


<summary>New LookML</summary>

dimension: shipping_city {
sql: ${TABLE}.shipping_city ;;
group_label: “Shipping Info”

dimension: shipping_state {
sql: ${TABLE}.shipping_state ;;
group_label: “Shipping Info”

dimension: shipping_street {
sql: ${TABLE}.shipping_street ;;
group_label: “Shipping Info”


`group_label` also interacts with dimension groups in pretty handy ways. For example, this LookML will add a special date calculation into the existing dimension group:

<details open>
<summary>Old LookML</summary>
  • dimension_group: created
    type: time
    sql: ${TABLE}.created_date

  • dimension: special_date_calculation
    sql: my_fancy_pants_sql
    group_label: ‘Created Date’


<summary>New LookML</summary>

dimension_group: created {
type: time
sql: ${TABLE}.created_date ;;

dimension: special_date_calculation {
sql: my_fancy_pants_sql ;;
group_label: “Created Date”


It would look like:

<img src="/uploads/default/original/2X/0/01f26e5283216633112fe343ca5fd89ac75f4e8c.png" width="318" height="261">

> Please keep in mind that there must be at least two fields in a group label for it to appear. Also, you can't group dimensions and measures together in the same `group_label`. Even if you give a dimension and measure exactly the same `group_label` there will still be one group under dimensions, and one group under measures.

Looker 3.44 Release Notes
Timeframes and Dimension Groups in Looker
[Retired] Calculating the difference between dates
(Michael Kaminsky) #2

This is awesome. Thanks y’all.

(Josh Andrews) #3

Is there any way to do multi-level group label nesting?

I have some pretty large and complex datasets, and I’d like to be able to do something like

  • Master Group
    • Sums
      • Sum Field 1
      • Sum Field 2
    • Percentages
      • Percentage Field 1
      • Percentage Field 2

(Nicole Beyer) #4

Hey @tuple!

This is not currently possible but I have passed the idea along to product/engineering for you!

(Josh Andrews) #5

Thanks, Nicole. Much appreciated. I’d be glad to demo in more detail what I am trying to do if it would be helpful.

(Brett Sauve) #6

@tuple In the example you gave, you only had 2 levels of organization. If that’s all you need, you could use view_label for the first 1st level of grouping and group_label for the 2nd level of grouping. But, if you want 2 levels of organization within the same view (for a total of 3 levels), then there isn’t really a way to do that currently as @nbeyer said. I suppose you could use label to name things with the same beginning so they would appear together when Looker did its alphabetic sort.

(Josh Andrews) #7

Hi Brett –

Yes, I need two (or even more!) levels of organization within the same view. I have already done the naming trick, but I don’t want to change field names too much because I want users to be able to understand something of the underlying data in Redshift. Also, I have hundreds of fields so even within a label group the sheer number of fields can overwhelm the user without the ability to have sub-groups.



(Lucas Chapin) #8

+1 to @tuple’s request of multilevel grouping. A use case for us is to have a time dimension group within another dimension group. e.g. in your example above, ‘Shipping Info’ would be the first level, with shipping time/date/etc. as a time group within the ‘Shipping Info’ group.

  • 1 to this request

(Shirin Hashim) #10

+1 to multilevel grouping


Is there a way to present a group as collapsed initially? Even if I collapse and save a Look, it seems to automatically expand, which to some degree defeats the purpose of grouping for ease of viewing/use.

(Brett Sauve) #12

@bgig I think that Looker will expand a list only if you’ve selected a field within it. Otherwise, the list should be closed by default. I don’t think it’s possible to modify either of these behaviors.


Brett - that’s not my experience.

I could find no way to get the list to start
collapsed. Before selecting anything, at the start of an new Explore, it
shows expanded in all cases I’ve tried… I am simply using group_labels on a set of dimensions.

I am on v. 3.54.16 if that matters.


That’s my experience as well.

(Brett Sauve) #15

@bgig and @ross I looked into this a bit more and found that the field groups should only start expanded if you only have a single view in your explore. For explores with multiple views (aka that have joins) they should start collapsed. Does this apply to your situation?

(Tig Newman) #16

For each old LookML code block in this article and its comments, we just added the New LookML equivalent code.


Brett - My example is a single view - the view is of a single, non-derived table; and the explore only exposes that one table. Seems odd that only a join scenario would collapse grouping fields?? Thanks for the continuing responses!

(Brett Sauve) #18

@bgig I can see where you’re coming from, I can open a feature request for you to potentially change that behavior.


Yes please!

(Segah A. Mir) #20

Overall, a very much needed feature that partially solves a problem of default redundant fields.

There are a couple of problems though:

  1. speed. With a large number of groupings, there is a significant delay in the time UI takes to load. I have now observed this across 3 models and tested against other factors, including # of view_labels and # of views/files. The groupings are the prime cause for delay.

  2. date groupings nest all dates together, making it unclear which date is which. This is a very common scenario:

in the events view, I might have a number of session-related timestamps, such as:

- dimension_group: session_start
  type: time

- dimension_group: session_end
  type: time

I would like to group these under a session group, but this will duplicate each of the timeframes in the UI (and a user won’t know which one belongs to which type of timestamp).