home User Guide Getting Started Help Center Documentation Community Training Certification
Looker keyboard_arrow_down
language keyboard_arrow_down
Looker documentation will be moving to cloud.google.com on August 22, 2022!
All the information you rely on will be migrated and all docs.looker.com URLs will be redirected to the appropriate page.
Access control and permission management

Looker admins can manage what a user or group of users can see and do in Looker by specifying the following access:

Data access, feature access, and content access for users and groups combine to specify what users can do and see in Looker.

Users and groups

In Looker there are both individual users and groups of users. Users are managed on the Users page of Looker’s Admin panel, while groups are managed on the Groups page of Looker’s Admin panel.

The best practice is to use groups to avoid the tedium of assigning, adjusting, and removing controls for users individually. Typically the combination of activities to allow for a user can be arranged by having that user belong to one or more groups. If no combination of groups is enough, consider creating a group with only one user, which lets you potentially expand that group to more people in the future. For access filters, consider using user attributes since you can assign user attributes to groups.

Controlling user content access

Looker folders let you organize sets of dashboards and Looks. They can also contain other folders, facilitating a nested hierarchy of organization.

Folders let you set access levels that determine which users may edit folder contents (such as Looks and dashboards), view the contents in a folder, and change settings:

Folders do not otherwise control what users can do on the Looker platform, or which data they can use to build their own content. To manage that level of access, see the Controlling Feature and Data Access section on this page.

The step-by-step instructions for adjusting folder access levels for users who are browsing content in Looker are discussed on our Organizing and managing access to content documentation page. Looker admins can also adjust folder access levels for all groups and users from the Content Access page of Looker. You can also view the Designing and configuring a system of access levels documentation page for information about instance-wide access level design.

Although content access is managed separately from feature access, the role assigned to a user can affect whether they can see Looks and dashboards listed in a folder, view a Look or dashboard, or manage a folder. A section below describes how feature access affects content access in more detail.

Controlling feature and data access

To control feature and data access in Looker you usually create a group of users (this is optional, but recommended) and assign that group to a role. A role ties together a set of permissions with a set of LookML models. The models themselves define which fields and data is available.

You can apply specific data limits to specific users with access filters. And, you can limit Looker developers to working with models based on particular databases by using projects.

You can also control access to specific Explores, joins, views, or fields by creating access grants. Access grants limit access to only users that have been assigned specific user attribute values.

If you want to achieve this … These are the basic steps you’ll take …
Control the actions a user can perform Create a permission set with the appropriate permissions, then assign a group or user to a role with that permission set
Control what fields a user can access Create a model with the appropriate fields, then assign a group or user to a role with that model
Control what data a user can access Create a model with the appropriate data limitations, then assign a group or user to a role with that model

- or -

Use access filters to limit a user to the appropriate data

- or -

Use user attributes to provide differing database credentials to a group or user

- or -

Use user attributes with access grants to restrict access to specific Explores, joins, views, or fields
Control what database connections a Looker developer can access Create a project with the appropriate connections, associate the project with a set of models, then assign a group or user to a role with those models

Feature access can also affect content access. See this section below for more details on how data access and feature access affect content access.

Building blocks you’ll need to understand


A role is a combination of one permission set, and one model set. The permission set defines what the role may do, and the model set defines which LookML models the role may see.

After you create a role you can assign an individual user, or a group of users, to that role. If you add some roles to an individual user, and other roles to a group that the user belongs to, the user will inherit all of those roles put together.

Some permissions are relevant to your entire Looker instance, others only apply to the models within the same role. See the Roles documentation page for more information.


Projects let you restrict which database connections may be used by which models. This can help you control which sets of data your Looker developers can interact with when they are creating models.

This restriction defined through projects also flows through to the Looker SQL Runner, which ensures that your developers cannot get access to prohibited database connections by using SQL Runner.

User attributes

User attributes let you assign arbitrary values to groups of users or individual users. These values are then used as inputs to various parts of Looker, customizing experiences for each user.

One way user attributes control access is by parameterizing database credentials to be specific to each user. This only has value if your database has multiple users with varying data access. See the User attributes documentation page for more information.

Another way user attributes control access is as part of access filters. Access filters let you utilize one or more user attributes as a data filter. For example, you might want to assign each user a company name, then make sure any content they see is filtered by that name. For a description of how to apply access filters, see the User attributes documentation page and the access_filter parameter documentation page.

User attributes also control access grants. An access grant specifies a user attribute and defines allowable values in that user attribute to grant access to an Explore, join, view, or field. You then use the required_access_grants parameter at the Explore, join, view, or field level to restrict access to those LookML structures to only those users who have the allowed user attribute values. For example, you could use an access grant to limit access to the salary dimension to only those users who have the value payroll in their department user attribute. For a description of how to define access grants, see the access_grant parameter documentation page.

Using the building blocks

Control feature access

Permissions control the types of activities that a user or group can do. This is how a user can get permissions:

  1. The best practice is to identify one or more groups of users that should have a permission set, creating a group if necessary. You can give permissions to individual users if desired.
  2. Create a permission set that contains the appropriate permissions.
  3. If some of the permissions to be assigned are model-specific, create or identify an existing model set.
  4. Create a role that combines the permission set and, if necessary, the model set.
  5. Assign the role from the Roles page. After the role exists, you also can assign the role to a user on the Users page.

You can assign multiple roles to a user or group. In that case, users will have all the permissions from all the roles they have. For example:

If you assign both roles to the same group of users, then they can see dashboards on both Model1 and Model2 but only can explore on Model2.

Control user access to Looker fields

The fields that a user can work with are controlled by the models that the user can access. This is how a user can get field access:

  1. Create a LookML model (or combination of LookML models) containing only the fields a user should have access to.
  2. Create a model set that contains those models, then assign it to a role. This is done on the Looker Roles page.
  3. To work with groups of users, which is usually our suggestion, create a group on the Looker Groups page. Then assign that group to the appropriate roles on the Roles page.
  4. To work with individual users, assign roles to those users from either the Users page or the Roles page.

You can assign multiple roles to a user or group. Users can then work with all models from all the roles that they have.

It’s important to note that the hidden parameter for fields is designed to create cleaner experiences for users, not to control field access. The hidden parameter hides fields from the field picker, but it won’t prevent a user from ever using that field. If someone sends them a link that uses that field they can see it, and other places in Looker will still show the field.

Control user access to data

There are several ways to control a user’s access to data, depending on the use case:

Just like the hidden field parameter is not intended for controlling field access, the hidden parameter for Explores does not prevent all users from viewing an Explore. The hidden parameter removes the Explore from the Explore menu, but if a user has saved content that references a hidden Explore, they will still have access to the Explore’s data.

If you are using single sign-on (SSO) embedding, be sure to configure data access controls via the SSO embed URL.

Control developer access to database connections

Unlike regular users, Looker developers are not fully constrained by models and access filters, because they can simply make additions or changes to LookML models. However, admins can still limit Looker developers to certain database connections by using projects. To do so:

  1. Create a project that restricts a certain number of models to a certain number of database connections. This is done on the Looker Manage Projects page.
  2. Create a model set that contains at least one of the models in the project, then assign it to a role. This is done on the Looker Roles page.
  3. To work with groups of users, which is usually our suggestion, create a group on the Looker Groups page. Then assign that group to the appropriate roles on the Roles page.
  4. To work with individual users, assign roles to those users from either the Users page or the Roles page.

If a Looker developer can see any model that is part of a project, they will be able to view all models that are a part of that project. For example, this could happen if you assigned a Looker developer to a role with only one model, but that model happened to be a part of a project that contained other models.

How content access and permissions interact

Content access is managed by users when they are viewing a folder, or managed by a Looker admin on the Content Access page in the Admin panel. The roles that are assigned to a user determine the user’s feature and data access. This affects what the user can do in a folder and whether they can view Looks and dashboards.

Viewing data in Looks and dashboards

To view a Look or dashboard’s data, the user must have at least View access to the folder where the content is stored.

Users must have access_data and see_looks permissions to select a Look and view its data. Users must have access_data and see_user_dashboards permissions to select a dashboard and view its data.

To see the data in a Look or dashboard tile, the user must have access to that data. Without the necessary data access:

In this example, the user has View access for the folder, data access for the data, and both access_data and see_looks permissions so can see lists of Looks and view those Looks. The user does not have access to see LookML or user-defined dashboards so no dashboards appear in the folder.

Viewing a folder and lists of Looks and dashboards

A user needs at least the View access level to a folder to view that folder and see the list of content stored inside that folder.

Users that also have at least see_looks permission see the titles of Looks in the folder. Users that also have at least see_user_dashboards permission will see the titles of dashboards in the folder. However, this does not imply that they can view the data of the Looks or dashboards.

In this example, the user has see_looks permission but does not have access_data permission. Thus the user can see the titles of Looks but can’t view the Look’s data. The user might or might not have the data access needed for the Look.

Users that have the access_data permission, but do not have either the see_looks or see_user_dashboards are not be able to see any folders or any content.

Modifying a folder

A user needs to have the Manage Access, Edit access level for a folder to be able to organize that folder, including copying and moving content, renaming and moving folders, and similar actions. Users must also have the manage_spaces permission to create, edit, move, and delete folders.

Making use of your user permission infrastructure (LDAP, SAML, and OpenID Connect)

If you already have an LDAP, SAML or OpenID infrastructure setup, you can use that system to manage user logins. The instructions for setting up LDAP can be found on the LDAP authentication page. The instructions for setting up SAML can be found on the SAML authentication documentation page. The instructions for setting up OpenID Connect can be found on the OpenID Connect authentication documentation page.

If you’ve configured groups in your LDAP, SAML, or OpenID Connect implementation, you can also use those groups within Looker. However, there are a few things to keep in mind:

You may also use LDAP to apply user-specific database connections to Looker queries, as described on the LDAP authentication documentation page.