User Guide Getting Started Help Center Documentation Community Training


view: view_name {
  parameter: field_name {}




A Looker identifier to name the parameter


There is a LookML parameter that is actually called “parameter”. The parameter parameter creates a filter-only field that can be used to filter to Explores, Looks and dashboards, but cannot be added to a result set. The values that a user selects for this filter-only field can dynamically change query results, labels, URLs and more when used with the {% parameter parameter_name %} and parameter_name._parameter_value Liquid variables.

A parameter name must:

There are many field types that can be assigned to a field created with parameter.

Specifying Allowed Values

If you want to limit the specific values that a user may choose for a parameter, you can do so by using allowed_value. Allowed values specify pairs of labels and values that a user may choose.

The allowed_value parameter is similar to the suggestions parameter, in that it allows you to set the filter options a user may choose from. However, the allowed_value parameter adds the extra functionality of mapping a user-friendly label with the value you want to use.

For example, this would produce a parameter that gives a user three filter options:

parameter: number_of_results { type: string allowed_value: { label: "Less than 500" value: "< 500" } allowed_value: { label: "Less than 10,000" value: "< 10000" } allowed_value: { label: "All Results" value: "> 0" } }

The label is what the user will see in the filter options, and the value contains the value you want to insert into logical statements with Liquid variables when developing dynamic content.

Using parameter in a Logical Statement

You can inject the value of a parameter into a logical statement using the {% parameter_name._parameter_value %} Liquid variable.

General Example

The following LookML block creates a parameter named date_granularity. Then, in the sql parameter of a measure, it uses {% parameter_name._parameter_value %} with the {% if %}, {% elsif %}, {% endif %} logical structure to determine the value of the measure, based on the value of the parameter:

parameter: date_granularity { type: unquoted allowed_value: { label: "Break down by Day" value: "day" } allowed_value: { label: "Break down by Month" value: "month" } } dimension: date { sql: {% if date_granularity._parameter_value == 'day' %} ${created_date} {% elsif date_granularity._parameter_value == 'month' %} ${created_month} {% else %} ${created_date} {% endif %};; }

Parameters of Type String

When using a parameter with type: string, the {% parameter_name._parameter_value %} Liquid variable requires that you enclose the values of the parameter with both single and double quotes. This is so that the single quotes are transmitted to the SQL, identifying the value as a string value. See the following example:

parameter: date_granularity { type: string allowed_value: { value: "Day" } allowed_value: { value: "Month" } } dimension: date { label_from_parameter: date_granularity sql: {% if date_granularity._parameter_value == "'Day'" %} ${created_date}::VARCHAR {% elsif date_granularity._parameter_value == "'Month'" %} ${created_month}::VARCHAR {% else %} NULL {% endif %} ;; }

In addition, if you want to include the value of a parameter with type: string in a label, you must precede the double quotes with the \ character:

label: "{% if test._parameter_value == \"'foo'\" %} 'SUCCESS' {% else %} 'FAIL' {% endif %}"

Parameters of Type YesNo

When using a parameter with type: yesno, the {% parameter_name._parameter_value %} Liquid variable produces a SQL statement that evaluates to true, as appropriate for your SQL dialect. Therefore, we suggest that you do not use parameter of type: yesno in a logical Liquid statement. Neither {% if yesno_parameter._parameter_value == 'Yes' %} nor {% if yesno_parameter._parameter_value %} will work properly.


In this example we create a parameter called item_to_add_up that lets a user choose what database column they want to sum. A corresponding measure called dynamic_sum then makes use of the {% parameter %} Liquid variable to perform the calculation:

parameter: item_to_add_up { type: unquoted allowed_value: { label: "Total Sale Price" value: "sale_price" } allowed_value: { label: "Total Cost" value: "cost" } allowed_value: { label: "Total Profit" value: "profit" } }   measure: dynamic_sum { type: sum sql: ${TABLE}.{% parameter item_to_add_up %} ;; value_format_name: "usd" }