Roles, permission sets, and model sets are used together to manage what users can do and what they can see. The Roles page in Looker’s Admin section lets you view, configure, and assign roles, permission sets, and model sets.
Definitions
- A role defines the privileges that a user or group will have for a specific set of models in Looker. You create a role by combining one permission set with one model set.
- 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 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.
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 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 everywhere. In contrast, if you allow someone toaccess_data
(a model-specific permission) in only one of their roles, they can only access the models that are a part of 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 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 users or groups. 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 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:
- Rename the role
- Assign or edit the permission set associated with that role
- Assign a model set to the role
- Assign the role to users and/or groups.
To delete a role, click the Delete button to the right of the role on the Roles page.
Default Roles
New in Looker 6.6, new installations will include a new set of default roles.
For new instances, Looker creates the following default roles, each of which includes a default permission set of the same name:
- Admin
- Developer
- User
- Viewer
Permission Sets
A permission set defines what a user or group can do. Permissions can be applied in one of two ways:
- Model-Specific: This type of permission is only applied to the model sets that are part of the same role.
- Instance-Wide: This type of permission applies to your Looker instance as a whole and exposes parts of the Admin menu to non-admin users. Non-admin users will be able to access content and functionality across the entire Looker instance — even if they haven’t been granted access to the particular model that uses that content.
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 group or user.
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 permissions it should include. 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
andsee_looks
privileges require theaccess_data
privilege to be selected first. - The
see_user_dashboards
privilege depends on thesee_looks
privilege, which in turn depends onaccess_data
privilege.
You cannot select a child privilege without first selecting its parent.
Permissions List
The
develop
andsee_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 assigndevelop
orsee_lookml
to a user, and you’ve allowed them 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.
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 either create dashboards from Spaces or define them in LookML. Users can see the LookML Dashboards Space, which includes all LookML dashboards. Users must have explore permission for any relevant model(s) to explore those dashboards. |
see_looks |
access_data |
Model Specific | Users can see saved Looks (but not dashboards) within Spaces. Users must have explore permission for any relevant model(s) to explore those Looks. Users will also need the View content access level to see Looks in Spaces. |
see_user_ dashboards |
see_looks |
Model Specific | Users can either create dashboards from Spaces or define them in LookML. Users can view user-defined dashboards in Spaces but must have explore permission for any relevant model(s) to explore those dashboards. Users will also need View content access to see dashboards in Spaces. |
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 | 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 | Users can save and edit Looks and dashboards. Users must have explore permission for any relevant model(s) to explore from those Looks and dashboards. |
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.This permission has an associated legacy feature. |
schedule_look_ emails |
see_looks |
Model Specific | Users can send or schedule data deliveries via email. You can set email domain whitelists on the Settings page of Looker’s Admin panel. |
schedule_external_ look_emails |
schedule_look_ emails |
Instance Wide | The same as schedule_look_emails , but users can send emails to any domain, regardless of your email domain whitelist settings. |
send_to_s3 |
see_looks |
Instance Wide | Users can send or schedule data deliveries to an Amazon s3 bucket. |
send_to_sftp |
see_looks |
Instance Wide | Users can send or schedule data deliveries via sftp. |
send_outgoing_ webhook |
see_looks |
Instance Wide | Users can send or schedule data deliveries via webhook. |
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.Users can also see the Datagroup update trigger option with a list of datagroups when scheduling a data delivery. This permission is required to see the Chat option in the Help menu. Users need this permission to access the Rebuild Derived Tables and 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 and Run in all models. |
deploy |
develop |
Instance Wide | Users can push their local LookML changes to production so that those changes become available to everyone. |
support_access_toggle |
develop |
Instance Wide | 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 | Users can create, edit, move, and delete Spaces. Users will also need the Manage Access, Edit content access permission. |
manage_homepage |
None | Instance Wide | Users can edit and add content to the sidebar that all Looker users see on their personalized home pages. |
manage_models |
None | Instance Wide | 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 | 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 | 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 | Users can see the Log page in the Admin section of Looker. |
see_users |
None | Instance Wide | 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. |
sudo |
see_users |
Instance Wide | 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 | Users can see the Scheduler Plans and History pages in the Admin section of Looker. |
see_pdts |
None | Instance Wide | Users can see the PDTs page in the Admin section of Looker. |
see_datagroups |
None | Instance Wide | Users can see the Datagroups page in the Admin section of Looker. |
update_datagroups |
see_datagroups |
Instance Wide | Users can trigger a datagroup, or reset its cache, via the Datagroups page in the Admin section of Looker. |
see_system_activity |
None | Instance Wide | 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:
- A model set controls which models in your LookML the permissions apply to (if those permissions are model-specific).
- 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 included. 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 documentation page. You may also find this Community topic useful, as it explains in greater detail how multiple models can be used to control user data access.