User Guide Getting Started Help Center Documentation Community Training
Editing and Validating LookML

Using the IDE

Looker’s Integrated Development Environment (IDE) has several features to assist you in writing LookML.


As you type, the IDE suggests possible parameters and values that are sensitive to the context of what you are typing. For example, the suggestions for a dimension’s type parameter will only include valid options for that parameter. Also, fields in sql parameters have to be marked with ${...}, so the IDE adds that syntax when suggesting fields.

Autosuggest automatically appears wherever it can be shown. To close it, press the escape key on your keyboard. To view it at any point, press Ctrl+Space (Windows) or Control-Space (Mac).

On-the-Fly Error Checking

The IDE catches syntax errors as you type. A red X in the gutter indicates a syntax error, which is underlined in red. When you hover over the red X, a short description of the problem appears.

The LookML Validator is still required to perform a full model validation. Some errors, such as an invalid field reference due to a missing join, require a holistic look at the model and therefore are only surfaced when the LookML Validator is run.

Context-Sensitive Help Panel

On the right side of the IDE is a context-sensitive help panel that dynamically updates based on the position of your cursor. The help panel:

Automatic Formatting

Select Format File from the gear menu to automatically indent your LookML file. The indentation indicates the hierarchy of parameters and subparameters, making your LookML easier to read and understand.


A small arrow appears in the gutter next to the start of each chunk of LookML. Pressing this arrow folds or unfolds that section of text so you can focus on just the section you want. The gear menu also provides Fold LookML and Unfold LookML options to fold or unfold all sections within the current file.

Marking Additions, Changes, and Deletions

In the LookML IDE, several indicators are always displayed when you are in Development Mode and have uncommitted changes.

If your project is enabled for folders in the IDE:

If your project is not enabled for folders in the IDE:

Adding Comments

You can add comments to your LookML to make it more readable. To add a single comment, use the # character:

dimension: name { sql: ${TABLE}.name ;; # This is the customer's full name }

You can comment out an entire block of code using keyboard shortcuts:

  1. Select the lines you want to comment out
  2. Press ⌘ + / on a Mac, or ctrl + / on a Windows computer

The IDE will add the # character to each of your selected lines.

Commenting Out SQL Blocks

If you are commenting out lines that are entirely within a SQL code block, manually add SQL comment notation.

Creating and Testing New Fields

As an example of editing LookML, we’ll add several fields and then test them.

Creating a Dimension

First we will add a new dimension to our users view that determines if a user is from either California or New York. The dimension will be type: yesno, which means it will return Yes if the user is from California or New York, and No if not.

The LookML for our new dimension looks like:

dimension: from_ca_or_ny { type: yesno sql: ${TABLE}.state = "California" OR ${TABLE}.state = "New York" ;; }

Add this dimension to the view file for the users view. Click Save to save your changes.

Check out substitution operators to learn more about ${TABLE}.state.

Creating a Measure

Next we will add a new measure to our user view that averages the age of our users. This measure will be type: average and aggregate over the column age.

The LookML for this new measure looks like:

measure: average_age { type: average sql: ${TABLE}.age ;; }

Add this measure to the view file for the user view. Click Save to save your changes.

Testing the Fields in the Explore

We can now test our new dimension and measure by querying them. After you save your changes, these fields will appear in the Field Picker in the Explore. An easy way to access the Explore for the current view is to use the drop-down menu next to the view file name:

Once we are in the users Explore, we can select the new fields to add them to a query. A query with both the new fields shows the average age of users who are from California or New York, versus users who are not:

You must be in Development Mode to access these new fields until you have committed and pushed your changes to production.

Validating Your LookML

When you are satisfied with your updates, you can save your changes. The IDE will alert you to any unresolved syntax errors within a single file.

Next, use the LookML Validator to perform a full model validation. Some errors, such as an invalid field reference due to a missing join, require a holistic look at the model and therefore are only surfaced when the LookML Validator is run. Be sure to validate your LookML changes before publishing them the production environment. Although validation will not catch every issue, such as database permission issues, it will prevent most errors.

The LookML Validator should not be confused with the Content Validator, which instead checks to see if the changes you’ve made will break any saved Looks.

When revalidating existing LookML, the LookML Validator scans only LookML files that have been updated since the last LookML validation, or files that are affected by updates:

Chat Team Tip: If you notice that the LookML validation takes a long time to complete, the first thing to check is the include parameter in your model file. If you include all of your view files (include: "*.view"), the LookML Validator will have to check them all, which can affect performance. If this is the case, update the model file’s include parameter so that only the needed view files are included.

Running Validation

To run the LookML Validator, click the Validate LookML button above the file list in the Looker IDE:

This will display a list of errors and other warnings that you should address:

The validator button will become available again if you make and save another change or fix:

Validation Messages

Looker displays validation messages after running validation on your LookML.

LookML dashboards show informational messages, rather than warnings, in the sidebar when permissive localization is enabled.

No LookML Issues

When there are no issues found by the validator, you will receive the No LookML Issues message in green.

LookML Errors

LookML errors are issues that could prevent queries from running. The number in parenthesis is the number of errors found (one error below):

Within the expanded list of issues you will see the reason why validation didn’t pass. Often times, if you click on the error, it will bring you directly to the problem row of code. You’ll see a red “X” next to the row. Hovering over it will provide more detailed error information in some cases:

Chat Team Tip: The validation error we are asked about most is “Unknown or inaccessible field.” Check out this Help Center article for the causes and what to do about it.

LookML Warnings

LookML warnings may not necessarily prevent a query from being run, but may still result in broken or unintended functionality for your users. As with errors, the number in parenthesis is the number of warnings found (34 warnings below):

As with LookML errors you can expand any warnings, jump to the problem code by clicking on them (in many cases), and hover over the exclamation point icon for more information:

LookML Deprecation Warnings

LookML deprecation warnings alert you to the fact that you’re using LookML parameters that have been phased out in favor of others. While your project will still function for the time being, eventually these parameters will be eliminated, which will result in future problems. It’s best to update parameters as you go to avoid creating an urgent, large amount of work when they are eliminated.

As with errors and warnings, you can expand deprecation warnings and jump to problem code by clicking on them (in many cases).

Deploying Your Changes

After you’ve validated that your changes will work properly, you can use Looker’s Git integration to commit and deploy your changes to production.

If you change field names that serve as filters in your Looks or dashboards, be sure to review the Filters section of your scheduled Looks and dashboards and update the filters as needed to reflect your changes. If a scheduled content delivery includes filters that no longer function (for example, if the referenced field has changed), the scheduled delivery could expose unfiltered data.