view_label (for Explores)

This page refers to theview_label parameter that is part of anExplore.

view_label can also be used as part of ajoin, described on theview_label (for joins) parameter documentation page.

view_label can also be used as part of adimension,measure, orfilter, described on theview_label (for fields) parameter documentation page.

Usage

explore: explore_name {  view_label:"desired label for the view"}
Hierarchy
view_label
Default Value
The name of the Explore

Accepts
A string

Definition

view_label changes the way that the group of fields from an Explore's base view will be labeled in the field picker.

Sometimesview_label is used to add an underscore in front of the view name so that it sorts alphabetically to be the top view in the field picker. Alternatively, you can use it when you need more than one view for modeling purposes, but the views represent the same entity as far as business users are concerned. For example, you might have one view defined in your LookML ascustomer and another ascustomer_facts, and want them to retain those names for modeling purposes. However, it might make sense for both of them to appear asCustomer to business users.

If you want to change the names of the fields themselves, you can use thelabel parameter.

Examples

Make thecustomer_facts Explore appear to business users to be part of theCustomers view:

explore: customer_facts {  view_label: "Customers"}

Make theproduct_facts Explore appear to users to be part of theProduct Info view:

explore: product_facts {  view_label: "Product Info"}

Things to consider

view_label has no effect other than changing the field picker appearance

When you change theview_label of anExplore, only the field picker is affected. The way that the Explore appears in theExplore menu, and the way that fields should be referenced in the LookML, are both unchanged.

Use proper capitalization when combining multiple views withview_label

If you want the fields from the Explore's base view to be merged with one of the Explore's joined views in the field picker, you'll need to make sure that the capitalization you use inview_label is correct. The capitalization you use should match how the view name appears in the field picker. Take this example:

explore: product {  view_label: "Product Info"  join: product_info {    sql_on: ${product.product_id} = ${product_info.product_id} ;;  }}

The way thatproduct_info will appear in the field picker isProduct Info; each word is capitalized, and underscores are changed to spaces. For this reason, we usedview_label: 'Product Info' instead ofview_label: 'product_info'.

A field'sview_label takes precedence over an Explore'sview_label

If a field in an Explore has aview_label, the field will appear under itsview_label, not the Explore'sview_label. Consider this example, where both an Explore and a dimension haveview_label values.

In the model file, the Explore is defined withview_label: "View Label on Explore":

explore: us_births {  label: "US births"  view_label: "View Label on Explore"}

In theus_births.view file, thestate dimension is defined withview_label: "View Label on Field":

view: us_births {  label: "US births"  dimension: state {    view_label: "View Label on Field"    type: string    sql: ${TABLE}.state ;;  }

In this case, thestate dimension'sview_label will override the Explore'sview_label, so in the Explore thestate dimension will appear under the "View Label on Field"view_label.

view_label affects the Explore's base view

This parameter is similar toview_label (for joins) but affects the Explore's base view instead of the joined views. Unlikelabel (for views), this parameter only affects the base view in that Explore.

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-09-16 UTC.