home User Guide Getting Started Help Center Documentation Community Training Certification
Looker keyboard_arrow_down
language keyboard_arrow_down
extends (for Explores)

This page refers to the extends parameter that is part of an Explore.

extends can also be used as part of a view, as described on the extends (for views) parameter documentation page.

extends can also be used as part of a LookML dashboard, as described on the Dashboard parameters documentation page.


explore: explore_name {
  extends: [explore_name, explore_name, …]



Default Value



Square brackets containing a comma-separated list of Explore names


The extends parameter allows you to build upon the content and settings from another Explore, using the other Explore as a starting point. If there are any conflicts, the extending Explore will use its own settings, overriding the settings of the Explore being extended. See the Reusing code with extends documentation page for the details of how Looker does this.

Check out LookML refinements.

Extending a view or an Explore is ideal for scenarios where you want to have multiple versions of the view or Explore. But if your goal is simply to modify a view or an Explore without editing the LookML file that contains it, you may want to use a refinement instead.

You can also use an extends parameter inside a refinement.

See the LookML refinements documentation page for more information and use cases.

When you’re extending an Explore, it’s important to have the view_name parameter in the Explore that is going to be extended. The view_name parameter defines the view on which an Explore is based. Its default value is the name of the Explore. If the base Explore doesn’t have a view_name specified, it defaults to the Explore name. But this doesn’t work for other Explores that are extending the base Explore, so we would get the “unknown view” error. In order for Looker to use the correct view file, we need to specify it using the view_name parameter. And since this will be needed in any extended version of the Explore, the best practice is to add it to the base Explore so it is consistently referenced any time the Explore is extended.

If your base Explore doesn’t already have a view_name parameter, you can just add the view_name parameter and specify the same value as your Explore’s name.

You may also want to use the view_label parameter in your base and extending Explores. The view_label parameter determines the label under which the view’s fields are grouped in the field picker (see the view_label (for Explores) parameter documentation page for an example). If you don’t specify a view_label for your base and extending Explores, they both will use the Explore name from the base Explore.


Here’s an example Explore that’s defined in our model file:

explore: orders { view_name: orders view_label: "Orders" # The normal contents of the Explore follow }

And here we add a new Explore that extends the orders Explore that we defined above:

explore: name_of_the_new_explore { extends: [orders] view_label: "Order Information" # The additional things you want to add or change # in the new Explore }

If you are extending an Explore that is based on an extended view, you will also need to use the from parameter. Add from to the extending Explore and assign it the name of the extended view.

explore: new_explore { extends: [orders] from: extended_orders_view #The normal contents of the Explore follow }

Using extends to limit fields for different users

A very handy use case of extending an Explore is to display only a subset of an Explore’s fields to certain users. For example, suppose you have a products Explore with all the available fields from the joined tables:

explore: products { view_name: products from: products join: inventory_items { type: left_outer sql_on: ${products.id}=${inventory_items.product_id} ;; relationship: many_to_one }   join: order_items { type: left_outer sql_on: ${order_items.inventory_item_id}=${inventory_items.id} ;; relationship: one_to_one } }

If you have a team who only needs to see product category and returns, you can extend the products Explore and use the fields parameter to specify that only the product category and returns fields are to be included:

explore: products_extended { extends: [products] fields: [products.category,order_items.returned_date] }

The products_extended Explore will display only these two fields: products.category and order_items.returned_date.

Extending an Explore across models

Explores are usually defined within a model file. If you want to extend an Explore, you can just define the extending Explore in the same model file, as in the examples above.

However, if you want to extend an Explore across multiple models, you must create a separate Explore file to use as a base file. Once you have defined the base Explore in its own file, you can include the Explore file in your model file and extend the Explore in your model file. You can find a detailed example in the Help Center article on Extending Explores to a Different Model.

Since you can include an Explore file in another Explore file, you can also share your base Explore file across multiple other Explore files, if need be.

Explore files will listen to the connection of the model in which they are included. Keep this in mind when you include Explore files in models that are configured with a connection that is different from the Explore file’s parent model. If the schema for the including model’s connection differs from the schema for the parent model’s connection, it can cause query errors.

Using metadata to see extensions for an object

If your Looker admin has enabled the IDE Metadata Sidebar Labs feature, you can click on an explore or a view parameter in the Looker IDE and use the metadata panel to see any extensions on the object, or to see what object it extends. See the Metadata for LookML objects documentation page for information.

Things to consider

When extending an object, be aware that localization rules apply to your extensions as well. If you are extending an object and then defining new labels or descriptions, you should provide localization definitions in your project’s locale strings files. See the Localizing your LookML model documentation page for more information.