Use sql_always_where to apply a query restriction that users cannot change

Please check out the original documentation for most up-to-date information.

sql_always_where enables you to apply a query restriction that users cannot change. The restriction will be inserted into the WHERE clause of the underlying SQL that Looker generates, for all queries on the Explore where sql_always_where is used. In addition to queries run by human users, the restriction will apply to dashboards, scheduled Looks, and embedded information that relies on that Explore.

The condition can be written in pure SQL, using your database’s actual table and column names. It can also use Looker references like:

• ${view_name.SQL_TABLE_NAME}, which references a different Looker view or a derived table. Note that SQL_TABLE_NAME in this reference is a literal string; you do not need to replace it with anything.
• ${view_name.field_name}, which references a Looker field. Using this method is better than referring to SQL columns directly because Looker can automatically include any necessary joins.

A sql_always_where condition is not displayed to the user, unless they look at the underlying SQL of any queries that they create.

The sql_always_where documentation page details the followings:

Usage

• Hierarchy
• Default Value
• Accepts
• Special Rules

Definition

Examples

Common challenges

• If you use raw SQL, you might need to use always_join
• Only use one sql_always_where per Explore

Things to know

• There is a similar parameter for the SQL HAVING clause
• If you want filters a user can change, but not remove, consider always_filter
• If you want user specific filters that can’t be changed, consider access_filter