Roles

On this Page
Docs Menu

Roles, Permission Sets, and Model Sets are used together to manage what users can do, and what they can see.

Definitions

  • A Model Set defines what data and LookML fields a user or group can see. You select a combination of LookML models to which a user or group should have access. It must be used as part of a role to have any effect.
  • A Permission Set defines what a user or group can do. You select a combination of permissions that you want to assign to a user or group. It must be used as part of a role to have any effect.
  • A Role is a combination of one permission set and one model set, and is used to assign a certain set of priveleges to a certain set of models for a user or group.

Model Sets

A Model Set defines what data and LookML fields a user or group can see. It is simply 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.

To create a model set, click the New Model Set button at the top of the Roles page. Looker will display a new page where you can enter a name for the model set and select the models that should be a part of it. Once you’ve configured the set as desired, click the New Model Set button that will be at the bottom of the page.

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

To learn more about models, see our model reference. You may also find this Discourse entry useful, as it explains in greater detail how multiple models can be used to control user data access.

Permission Sets

A Permission Set defines what a user or group can do. It is simply a list of permissions that you want a user or group to have. Permissions can be applied in one of two ways:

  • Model Specific: This type of permission is only applied to the model sets (described above) that are a part of the same role.
  • Instance Wide: This type of permission applies to your Looker instance as a whole.

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

Default Permission Sets

Looker includes several default permission sets that you can start with:

  • Admin
  • Developer
  • User
  • Dashboard Only User

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.

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 new page where you can enter a name for the permission set and select the permissinos that should be a part of it. Once you’ve configured the set as desired, click the New Permission Set button that will be 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:

  • The access_data privilege can be selected at any time.
  • The see_lookml_dashboards and see_looks privileges require the access_data privilege to be selected first.
  • The see_user_dashboards privilege depends on the see_looks privilege, which in turn depends on access_data privilege.

Looker does not allow you to select a child privilege without selecting its parent first, which ensures that the permissions are configured correctly.

Permissions List

The following list describes all of the permissions that are available in Looker:

Permission Depends On Type Definition Added In
access_data None Model Specific Allows users to access data from Looker, but only the data you allow. This permission is necessary for almost all Looker functions. 3.2
see_lookml_
dashboards
access_data Model Specific Looker allows dashboards to be created by users, or defined in LookML. This permission allows users to see the “LookML Dashboards” space, which includes all LookML dashboards. 3.6
see_drill_
overlay
access_data Model Specific Allows users to see the results of drilling into a dashboard tile, but not the ability to explore those results. If explore is granted this permission is also automatically granted (even if it isn’t checked). 3.54
see_looks access_data Model Specific Allows users to see saved looks (but not dasbhoards) within spaces. Note that the explore permission is still required to explore and view those looks. 3.2
see_user_
dashboards
see_looks Model Specific Looker allows dashboards to be created by users, or defined in LookML. This permission allows users to see user created dashboards in spaces. 3.6
explore see_looks Model Specific Allows users to 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). 3.2
create_table_
calculations
explore Instance Wide Before Looker 3.44: determines whether or not table calculations can be viewed, added, and edited while exploring.

As of Looker 3.44: table calculations can be viewed by anyone with the explore permission, but can only be added or edited with this permission.
3.18
save_content see_looks Instance Wide Allows users to save and edit Looks and dashboards. 3.8
create_public_
looks
save_content Model Specific Looker allows users to mark a saved Look as public, which will then generate URLs that allow access to that report without authentication. This permission determines whether or not a user is allowed to do this. 3.4
send_outgoing_
webhook
save_content Instance Wide Looker allows users to have data sent to a URL, via webhook, on a defined schedule. This permission determines whether or not a user is allowed to do this. 3.46
send_to_s3 save_content Instance Wide Looker allows users to have data sent directly to an S3 bucket. This permission determines whether or not a user is allowed to do this. 4.2
schedule_look_
emails
save_content Model Specific Looker allows users to have data sent to them via email on a defined schedule. This permission determines if a user is allowed to do this. You can set email domain whitelists on the General page of Looker’s admin settings. 3.8
schedule_external_
look_emails
schedule_look_
emails
Instance Wide The same as schedule_look_emails, but users will be allowed to send emails to any domain, regardless of your email domain whitelist settings. 3.14
download_with_
limit
see_looks Model Specific Allow users to download queries (as csv, Excel, etc), but always require that they specify a row limit, which can help to avoid memory problems on your instance for very large downloads. 3.8
download_without_
limit
see_looks Model Specific The same as download_with_limit, but does not require the user to specify a row limit. 3.8
see_lookml see_looks Model Specific Allows users to have read-only access to your LookML code, and allows them to see the underlying SQL that was run for a given Explore. If you want a user to be able to edit LookML you must also give them the develop permission. This permission also interacts with model sets in a potentially unexpected way, as described below. 3.2
develop see_lookml Model Specific Allows a user to make local changes to your LookML code, but will not allow them to make those changes available to everyone unless they also have the deploy permission. This permission also interacts with model sets in a potentially unexpected way, as described below. 3.2
deploy develop Instance Wide Allows a user to push their local LookML changes to production, so that those changes become available to everyone. 3.4
use_sql_runner see_lookml Model Specific Allows users to use the SQL Runner to run raw SQL against their allowed connections. 3.4
manage_spaces None Instance Wide Allows users to create, edit, move and delete spaces. 3.4
manage_models None Instance Wide Each LookML model is mapped to a specific set of database connections on the Manage Projects page. This permission allows the user to configure these mappings. Therefore, users with this permission have access to every database connection. If you want developers to be limited to certain connections do not grant this permission and leave the model connection mapping to Admins. 3.8
create_prefetches None Instance Wide Allows an API user to make calls to the pre-fetch API endpoint, which you can read more about here. 3.36
login_special_
email
None Instance Wide Allows a user to login 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, etc who may not be a part of your normal authentication system. 3.14
see_queries None Instance Wide Allows users to 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. 3.48
see_logs None Instance Wide Allows users to see the Logs page in the Admin section of Looker. 3.48
see_users None Instance Wide Allows users to 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 3.48
sudo see_users Instance Wide Allows a user to sudo (i.e. act as and temporarily inherit the permissions of) another user by clicking the Sudo button on the Users page. The sudo permission does not give a user the ability to act as a user with the administrator role. 3.48
see_schedules None Instance Wide Allows a user to see the All Scheduled Plans and Scheduler History pages in the Admin section of Looker. 3.52
see_pdts None Instance Wide Allows a user to see the PDTs page in the Admin section of Looker. 3.50

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 these permissions to a user, and you’ve allowed them to see any model that is a part of a project, they will be able to see and develop the LookML for all models on that project. However, they will still not be able to query models that you have not allowed.

Roles

As mentioned above, to make use of a model set or permission set you must combine them in a role.

A Role is a combination of one permission set and one model set. The name of a role usually represents a type of person in your organization, such as an administrator, a developer, or a member of the finance department, though it doesn’t have to.

It’s important to note that users can have more than one role. This can be useful for users who play multiple roles in your company, or when you want to execute complex access 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 everywhere. In contrast, if you allow someone to access_data (a model-specific permission) in only one of their roles, they can only access the models that are a part of that role.

To create a role, click the New Role button at the top of the Roles page. Looker will display a new 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 groups or users. Once you’ve configured the role as desired click the New Role button that will be at the bottom of the page.

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

Still have questions?
Go to Discourse - or - Email Support
Top