Grouping Fields Within Views (3.44+)

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.

6dbce5bd83d2c18dde4767a2109fd64fbda39362.png

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

453d0d2e12dca16e5b2dd863085f97928a5feb9f.png

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:

4ab5ac1d29fba447efa55d07b51d08759d5c98b7.png

You would achieve this with the following 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"
}

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:

dimension_group: created {
  type: time
  timeframes: [date, week, month]
  sql: ${TABLE}.created_date ;;
}

dimension: special_date_calculation {
  sql: my_fancy_pants_sql ;;
  group_label: "Created Date"
}

It would look like:

01f26e5283216633112fe343ca5fd89ac75f4e8c.png

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.

7 36 6,947
36 REPLIES 36

This is awesome. Thanks y’all.

tuple
Participant I

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

Hey @tuple!

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

tuple
Participant I

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

@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.

tuple
Participant I

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.

Thanks,

Josh

luc1
Participant I

+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.

ross2
Participant III
  • 1 to this request

+1 to multilevel grouping

bgig
Participant I

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.

@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.

bgig
Participant I

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.

ross2
Participant III

That’s my experience as well.

@bgig and @ross2 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?

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

bgig
Participant I

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!

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

bgig
Participant I

Yes please!

segahm
Participant IV

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).

Grouping fields has been incredibly helpful. I wish I could specify a group_label in a join for an explore that would override any existing group_labels in the underlying view. This would allow for more flexibility and customization with group_labels & view_labels.

+1 to multi-level grouping

Luis3
Participant I

+1 to multi-level grouping

Alex_Hancock
Participant IV

+1 to multi-level grouping

+1 to multilevel grouping

+1 to multilevel grouping

+1 to multilevel grouping

Jumping on this as well - +1 to multilevel grouping

Thanks @chobbs I’ve passed your +1 to the product team!

CaitlinK
Participant II

Bump! The feature request thread to add dimension groups underneath group labels is here. That’s a subset of this request, but it would be a great start. Go vote! I’ll send you an invisible internet hug. You might also be interested in this request to allow ordering of field picker list items, including groups.

+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.

Anyone knows if we have this feature yet? I’m encountering the exact same situation like this with a time dimension under a group

+1 to this request! Would be extremely helpful for unlimited levels of nesting to group related topics

+1 to this request

+1 to multilevel grouping, PLEASE!

Adding my +1 to multilevel grouping

+1 to multilevel grouping 

Top Labels in this Space
Top Solution Authors