home User Guide Getting Started Help Center Documentation Community Training Certification
menu
close
settings
Looker keyboard_arrow_down
language keyboard_arrow_down
English
Français
Deutsch
日本語
search
print
Roles

Roles, permission sets, and model sets are used together to manage what users can do and what they can see. The Roles page in the Users section of the Admin menu lets you view, configure, and assign roles, permission sets, and model sets.

Definitions

Assigning Roles

A role is a combination of one permission set and one model set. It’s a common convention to name roles after types of people or groups of people in your organization — administrator, Looker developer, Finance team — although you are welcome to follow your own naming conventions.

A user can have more than one role in Looker. This can be useful when you have users who play multiple roles in your company, or when you want to create complex systems of access to your models.

Adding users to multiple roles has important implications for how their permissions are applied. For example, if you allow someone to save_content (an instance-wide permission) in only one of their roles, they will be allowed to save content from any model. In contrast, if you allow someone to access_data (a model-specific permission) in only one of their roles, they can access only the models that are specified in that role.

Multiple roles can also cause unexpected effects on dashboards. See the Managing Business User Features documentation page for information about dashboards and multiple roles.

To create a role, click the New Role button at the top of the Roles page. Looker will display a page where you can enter a name for the role, choose a permission set, and choose a model set. You will also be able to assign the role to a set of users or groups. Once you’ve configured the role as desired, click the New Role button at the bottom of the page.

After a role has been created, you can edit it by clicking the Edit button to the right of the role on the Roles page. This will take you to that role’s page, where you can:

To delete a role, click the Delete button to the right of the role on the Roles page.

Default Roles

For new instances, Looker creates the following default roles, each of which includes a default permission set of the same name:

Permission Sets

A permission set defines what a user or group can do. Admins can use Looker’s default permission sets or create original permission sets, keeping in mind permission dependencies.

All the available permissions, and their types, are discussed in more detail below.

Default Permission Sets

For new installations, Looker includes several default permission sets that you can start with:

Permission Set Included Permissions
Admin All permissions
Developer access_data, create_table_calculations, deploy, develop, download_without_limit, explore, manage_spaces, save_content, schedule_look_emails, see_drill_overlay, see_lookml, see_lookml_dashboards, see_looks, see_sql, see_user_dashboards, use_sql_runner
User access_data, create_table_calculations, download_without_limit, explore, manage_spaces, save_content, schedule_look_emails, see_drill_overlay, see_lookml, see_lookml_dashboards, see_looks, see_sql, see_user_dashboards
Viewer access_data, download_without_limit, schedule_look_emails, see_drill_overlay, see_lookml_dashboards, see_looks, see_user_dashboards
LookML dashboard user access_data, see_lookml_dashboards
User who can’t view LookML access_data, create_table_calculations, download_without_limit, explore, manage_spaces, save_content, schedule_look_emails, see_lookml_dashboards, see_looks, see_user_dashboards

You’ll see these permission sets appear as options when you create a new role. If you select one of these permission sets, Looker will display the list of permissions it includes.

The Admin permission set cannot be edited or deleted, and cannot be assigned to a role. It is assigned only to the Admin role, which also cannot be edited or deleted. The only way to grant the Admin permission set to a user or group is to add the Admin role to that user or group.

Creating Permission Sets

To create a permission set, click the New Permission Set button at the top of the Roles page. Looker will display a page where you can enter a name for the permission set and select the permissions it should include. Once you’ve configured the set as desired, click the New Permission Set button at the bottom of the page.

After a permission set has been created, you can edit or delete it by clicking the Edit or Delete buttons to the right of the permission set on the Roles page.

Permissions and Dependencies

Some permissions depend on others to work properly. For example, it makes sense that someone who wants to develop in LookML must first be able to see LookML.

When you create a permission set you’ll see the available permissions in an indented list. If a privilege is indented under another (parent) privilege, you must select the parent privilege first. Consider this example:

In this case Looker uses indentation to indicate that:

You cannot select a child privilege without first selecting its parent.

Permissions List

The develop and see_lookml permissions interact with model sets in a potentially unexpected way. In Looker’s IDE, a single project can contain multiple model files. If you assign develop or see_lookml to a user, and you’ve allowed that user to see any model that is a part of a project, they will be able to develop or see the LookML for all models in that project. However, they will still not be able to query models that you have not allowed.

Permissions can be classified as one of three types:

The following list describes all of the permissions that are available in Looker, in the order in which they appear on the New Permission Set page in the Admin section:

Permission Depends On Type Definition
access_data None Model Specific Users can access data from Looker, but only the data that admins specify. This permission is necessary for almost all Looker functions.

A user with this permission, if given access to any model in a given project, can access any file in the Data section of that project (such as a JSON custom map file).
see_lookml_
dashboards
access_data Model Specific Users can see the LookML Dashboards folder, which includes all LookML dashboards. Users must have explore permission for any relevant models to explore those dashboards. Users that also have the develop permission can create LookML dashboards.
see_looks access_data Model Specific Users can see saved Looks (but not dashboards) within folders. Users must have explore permission for any relevant models to explore those Looks. Users will also need the View content access level to see Looks in folders.
see_user_
dashboards
see_looks Model Specific Users can view user-defined dashboards in folders but must have explore permission for any relevant models to explore those dashboards. Users also need View content access to see dashboards in folders. Users who also have both the save_content permission and Manage Access, Edit content access to a folder can create user-defined dashboards in that folder.
explore see_looks Model Specific Users can access and use the Explore page to generate reports. Without this permission, users can only view saved dashboards (if see_lookml_dashboards or see_user_dashboards has been granted).
create_table_
calculations
explore Instance Wide nn Users can view, edit, or add table calculations and custom fields; users with only the explore permission can only view table calculations and custom fields.
save_content see_looks Instance Wide nn Users can save and edit Looks and dashboards. Users must have explore permission for any relevant models to explore from those Looks and dashboards. Users must have download_with_limit and/or download_without_limit permissions to download the content.
create_public_
looks
save_content Model Specific Users can mark a saved Look as public, which will then generate URLs granting access to that report without authentication.
download_with_
limit
see_looks Model Specific Users can download queries (as CSV, Excel, and other formats) but must specify a row limit of 5,000 or fewer to avoid memory problems from large downloads on the instance.
download_without_
limit
see_looks Model Specific The same as download_with_limit, but does not require the user to specify a row limit. Downloading all results for some types of queries may require substantial memory, potentially causing performance issues or even crashing the Looker instance.
schedule_look_
emails
see_looks Model Specific Users can send or schedule email deliveries of any Looks, dashboards, and queries with visualizations to which they have data access. Users can schedule delivery to occur after a datagroup has been triggered, has managed the cache, and has rebuilt relevant PDTs.

To send or schedule System Activity dashboards, users must have access to all models.

Users who also have create_alerts permissions can send email alert notifications.

You can set email domain whitelists on the Settings page of the Admin panel. There are additional considerations for embed users.

ADDED6.24 This permission is applied to individual models or model sets, rather than across the entire Looker instance.
schedule_external_
look_emails
schedule_look_
emails
Model Specific The same as schedule_look_emails, but users can email Looks, dashboards, and queries with visualizations to any domain, regardless of the email domain whitelist settings. Users who also have create_alerts permissions can set alerts that send notifications to emails with any domain.

ADDED6.24 This permission is applied to individual models or model sets, rather than across the entire Looker instance.
create_alerts see_looks Instance Wide nn Users can create alerts on dashboard tiles to receive notifications when specified conditions are met or exceeded. Admins can access the alerts admin pages.
follow_alerts see_looks Instance Wide nn Users can view and follow public alerts.
send_to_s3 see_looks Model Specific Users can send or schedule data deliveries to an Amazon S3 bucket. Users can schedule delivery to occur after a datagroup has been triggered, has managed the cache, and has rebuilt relevant PDTs.

ADDED6.24 This permission is applied to individual models or model sets, rather than across the entire Looker instance.
send_to_sftp see_looks Model Specific Users can send or schedule data deliveries via SFTP. Users can schedule delivery to occur after a datagroup has been triggered, has managed the cache, and has rebuilt relevant PDTs.

ADDED6.24 This permission is applied to individual models or model sets, rather than across the entire Looker instance.
send_outgoing_
webhook
see_looks Model Specific Users can send or schedule data deliveries via Webhook. Users can schedule delivery to occur after a datagroup has been triggered, has managed the cache, and has rebuilt relevant PDTs.

ADDED6.24 This permission is applied to individual models or model sets, rather than across the entire Looker instance.
send_to_
integration
see_looks Model Specific Users can send or schedule data deliveries to the third-party services integrated with Looker via the Looker Action Hub. If using custom actions with user attributes, users must have this permission and have a non-null and valid user attribute value for the specified user attribue to deliver Looker content to that action destination. This permission is not related to data actions. Users can schedule delivery to occur after a datagroup has been triggered, has managed the cache, and has rebuilt relevant PDTs.

ADDED6.24 This permission is applied to individual models or model sets, rather than across the entire Looker instance.
see_sql see_looks Model Specific Users can access the SQL tab while exploring and any SQL errors caused by their queries.
see_lookml see_looks Model Specific Users have read-only access to LookML. Users must have this permission to see the Go to LookML link in the field picker.

If you want a user to be able to edit LookML you must also give them the develop permission. This permission interacts with model sets in a potentially unexpected way, as described above.
develop see_lookml Model Specific Users can make local changes to LookML but will not let them make those changes available to everyone unless they also have the deploy permission. This permission interacts with model sets in a potentially unexpected way, as described above.

This permission is required to see the Chat option in the Help menu. Users need this permission to access the Rebuild Derived Tables & Run option in the Explore gear menu. Note that this is not model-specific, so if a user has this permission in one model, they will have access to Rebuild Derived Tables & Run in all models.
deploy develop Instance Wide nn Users can push their local LookML changes to production so that those changes become available to everyone.
support_access_toggle develop Instance Wide nn Users can enable or disable access by Looker analysts to your Looker instance.
use_sql_runner see_lookml Model Specific Users can use SQL Runner to run raw SQL against their allowed connections.
see_drill_
overlay
access_data Model Specific Users can see the results of drilling into a dashboard tile but cannot explore those results. If explore is granted, this permission is also automatically granted (even if it isn’t checked).
manage_spaces None Instance Wide cn Users can create, edit, move, and delete folders. Users will also need the Manage Access, Edit content access permission.
manage_homepage None Instance Wide nn Users can edit and add content to the sidebar that all Looker users see on the pre-built Looker homepage.
manage_models None Instance Wide cn Each LookML model is mapped to a specific set of database connections on the Manage LookML Projects page. With this permission, users can configure these mappings and create new projects. Non-admin users granted this permission will have access to all connections allowed by the models to which they have access.
create_prefetches None Instance Wide Allows API calls to the pre-fetch API endpoint, which you can read more about in this Community topic.
login_special_
email
None Instance Wide Users can log in with traditional email/password credentials, even if other login mechanisms (such as Google, LDAP, or SAML) have been enabled on your instance. This can be useful for consultants or others who may not be a part of your normal authentication system.
embed_browse_spaces None Instance Wide nn Enables the content browser for single sign-on (SSO) embeds. If you are using SSO embeds you should give this permission to users who have the save_content permission.
see_queries None Instance Wide cm Users can see the Queries page in the Admin section of Looker. This privilege does not give a user the ability to terminate a query on the Queries page.
see_logs None Instance Wide cm Users can see the Log page in the Admin section of Looker.
see_users None Instance Wide cm Users can see the Users page (but not the Groups page) in the Admin section of Looker. This privilege does not give a user the ability to create new users, see or create API credentials, reset passwords, or otherwise modify users or privileges. A user granted this permission can see all users in all groups on an instance, even on a closed system. A user can see all group names and all role names, which some companies may consider sensitive.
sudo see_users Instance Wide cm Users can sudo (in other words, act as and temporarily inherit the permissions of) another user by clicking the Sudo button on the Users page.

The sudo permission does not allow a non-admin to sudo as an admin, but a non-admin could potentially escalate their privileges by using sudo, so exercise caution.
see_schedules None Instance Wide cm Users can see the Scheduler Plans and History pages in the Admin section of Looker.
see_pdts None Connection Specific Users can see the PDTs page in the Admin section of Looker and view information about PDTs from projects that use any connection associated with models for which they have data access.

ADDED6.22 This permission is applied to connections to which users have data access, rather than across the entire Looker instance or to individual models or model sets.
see_datagroups None Model Specific Users can see the Datagroups page in the Admin section of Looker. Users can see connection names, model names, and other information about datagroups defined in a model for which they have data access.

ADDED7.8 This permission is applied to individual models or model sets, rather than across the entire Looker instance or to connections.
update_datagroups see_datagroups Model Specific Users can trigger a datagroup, or reset its cache, via the Datagroups page in the Admin section of Looker. Like users with the see_datagroups permission, users with update_datagroups can see datagroups defined in projects that use a model for which they have data access.

ADDED7.14 This permission is applied to individual models or model sets, rather than across the entire Looker instance or to connections.
see_system_activity None Instance Wide cm Users can access the System Activity Explores and dashboards and the internal i__looker database to view usage, history, and other metadata about a Looker instance.

Model Sets

A model set defines what data and LookML fields a user or group can see. Each set is a list of LookML models to which a user or group should have access. You can think of a model set as performing two functions:

  1. A model set controls which models in your LookML the permissions apply to (if those permissions are model specific).
  2. A model set limits what data and LookML fields a user can see, because each model is connected to a specific database connection and contains certain LookML fields.

Creating a Model Set

To create a model set:

  1. Click the New Model Set button at the top of the Roles page.

  2. Looker displays the New Model Set page. Enter a name for the new model set.

  3. Select the model or models that should be included in the new model set.

  4. Click the New Model Set button at the bottom of the page.

Starting in Looker 6.24, models that are included in pending projects appear in the Models list on the New Model Set and Edit Model Set pages.

Deleting or renaming a model will not change any model sets that include that model. When a model is removed or renamed, we recommend that Looker admins also remove that model’s name from any associated model sets, using the Edit Model Set page. Removing a deleted model’s name from a model set prevents a new model with the same name from unintentionally being included in that model set.

To learn more about models, see the Model Parameters documentation page.

Creating Multiple Models and Model Sets

As an example of using multiple model sets to limit access to data, imagine you have two teams, Marketing and Support. These two teams should not have access to the entire model. You can create two different models, thelook_marketing and thelook_support, that include only the views and fields that are appropriate for their respective teams:

Then, create a model set for each team and grant access to the appropriate model:

Next, create a new role for that group of users and limit their model set to one you just created:

Editing a Model Set

After a model set has been created, to edit it:

  1. On the Roles page, click the Edit button to the right of the model set you want to edit.

  2. Looker displays the Edit Model Set page. If desired, enter a new name for the model set.

  3. Add or remove any models from the model set.

  4. Click the Update Model Set button at the bottom of the page.

Starting in Looker 6.24, models that are included in pending projects appear in the Models list on the New Model Set and Edit Model Set pages.

Deleting or renaming a model will not change any model sets that include that model. When a model is removed or renamed, we recommend that Looker admins also remove that model’s name from any associated model sets, using the Edit Model Set page. Removing a deleted model’s name from a model set prevents a new model with the same name from unintentionally being included in that model set.

Deleting a Model Set

To delete a model set, on the Roles page, click Delete to the right of the model set you want to delete:

Top