The Users page in the Users section of the Admin menu lists all of the user accounts on your Looker instance:
Viewing and Searching Users
The users are listed in a table that shows the following basic information:
|ID||A user ID assigned by Looker at the time of user creation|
|Name||The user’s actual name, which they enter when they initially sign up|
|Credentials||The user’s username, which is an email address|
|Groups||A list of groups the user belongs to|
|Roles||A list of roles assigned to the user|
|Actions||Actions you can take for a user|
You can sort the table by either the ID or Name column by clicking on the column’s header.
You can also search the Name and Credentials columns by entering a search term into the search box in the upper right and pressing [Enter].
To add a user, simply click the Add Users button in the upper left of the page. In the resulting dialog box, you can type or paste a comma-separated list of email addresses and select the roles and groups that will be assigned to each. Click the Add Users button when you’re done to create the users and send sign-up emails if you’ve selected the Send setup emails checkbox.
To edit a user, click the Edit button on the right-hand side of their row. There you’ll be able to adjust many settings:
Enable or disable a user’s account. You may want to consider disabling user accounts instead of totally deleting them.
Add or edit the user’s first name, if applicable. You aren’t required to add a value here, but it is useful for organizational purposes.
Add or edit the user’s last name, if applicable. You aren’t required to add a value here, but it is useful for organizational purposes.
Add or edit the user’s email address. When the user logs into Looker, this will serve as their username.
The Locale field sets the user-interface language and model locale for a user.
If you would like the user to view certain user interface (UI) text in a specific language, Looker supports the UI translations shown in the table below. Enter the code in the Locale field.
If you would like the user to view a localized version of one or more data models, enter the title of the model’s strings file for that locale in the Locale field.
If you would like the user to view both model localization and Looker’s built-in UI translations, the model’s strings file should have the same name as the appropriate locale code in the table below, and that code should be entered in the Locale field.
To confirm the Locale setting, click Save at the bottom of the page.
|Language||Locale Code and Strings Filename|
|Hebrew (left-to-right support only)||
UI language support for Hebrew is left-to-right.
For users with no Locale set, Looker uses the locale chosen on the Localization page of the Admin panel as the default locale, and if no locale is set there, Looker defaults to
Setting a Custom Locale
Looker developers can create custom locales to use for model localization only. Custom locale codes are designated by the titles of the string files created in the model localization process. For example, if a developer creates a
tag_PH.strings.json file, that custom locale can be applied to users by:
Clicking on the Locale field.
Entering the custom locale code. Once you begin typing in the field, any pre-existing text will disappear.
Clicking Create “tag_PH”.
- Clicking the Save button at the bottom of the page.
Once created, the code will be added to the user’s locale drop-down menu.
Currently, the Looker UI does not support custom locales. If you use a custom locale in a user’s Locale field, that user’s UI defaults to the language set in the instance locale.
Looker's default number format setting for numbers that appear in data tables and visualizations is 1,234.56. However, the number format can be set to any of the following:
- 1,234.56: Thousands separated with commas; decimals separated with a period
- 1.234,56: Thousands separated with periods; decimals separated with a comma
- 1 234,56: Thousands separated with spaces; decimals separated with a comma
For more information about and examples using the Number format setting, see the Localizing Number Formatting documentation page.
If you’ve enabled user specific time zones on your Looker instance, you can select the time zone that will be used when this user runs a query in Looker.
If you need to reset a password, you can send a reset link to the email address specified above by clicking the Send reset link button. The reset URL that is sent to the user will be displayed. See the Password Requirements documentation page to learn about specifying password complexity requirements in Looker. If the user does not reset their password within one hour, the password’s reset link will expire.
You will see this option if you have enabled two-factor authentication (2FA) on your instance. Click the Reset button to reset 2FA for the user. This causes Looker to prompt the user to rescan a QR code with the Google Authenticator app the next time they attempt to log in to the Looker instance.
An API3 key is used to access the Looker API. API3 keys are created by Looker and consist of a Client ID and a Client Secret. Looker requires an API3 key for the following:
- Executing commands via the Looker API.
- Accessing Looker’s interactive API documents (if the Looker instance is configured to require API login to see API documents).
To generate API keys, click the Edit Keys button from the Edit Users page. This will open the Edit User API3 keys page, where you can see the existing API3 keys or click the New API3 key button to generate a new key.
The API3 keys have the same permissions as the user account from which they were created.
The best practice is to create dedicated user accounts for API scripts — one user account for each script. That way, you can configure a user account with the specific set of permissions that allow the script to perform its function, and only its function. For example, for an API script that runs queries, you can create a user account with the
access_data permission, but no other permissions.
This technique lets you increase security by compartmentalizing a script’s access. Also, if you ever need to stop a script, you can simply disable (or delete) that script’s user account. Be sure to read Removing User Access before deleting any user account.
You can select the roles this user should have, if you want to assign roles individually. See the Roles page for more information on configuring roles, or the Permissions Management page for a broader discussion of Looker permissions.
We generally suggest assigning roles to groups instead of assigning roles directly to individual users.
Roles from Groups
If the user is assigned to any groups, they may have inherited some roles from those groups. These roles are listed here.
Select the groups this user should belong to. Users can also be added to groups on the groups page.
Set and unset the values of a user’s user attributes. Values assigned to an individual user always override any values assigned as a result of membership in a group. System settings are not editable.
Removing User Access
If you want to remove a user’s access to Looker you can either disable their account or delete their account. For most situations, the best practice is to disable the account.
Differences between disabling and deleting a user account are described in the following table:
|The user can log in to the Looker instance||No||No|
|The user’s personal folder||Still exists||Deleted|
|Looks and dashboards in the user’s personal folder||Still exist||Moved to the Trash folder|
|Looks and dashboards the user saved to a Shared folder||Still exist in the Shared folder||Still exist in the Shared folder|
|Schedules created by the user||Schedules are stopped||Schedules are deleted|
|Schedules based on the user’s content, but created by another user||Schedules continue to run||Schedules are deleted|
|Boards created by the user||Still exist||Still exist|
|Alerts created by the user||Remain active, but are not visible or editable from the dashboard on which the alert is set unless self-assigned by another active user. Admins can edit or self-assign the alert from the Alerts management admin page in the Admin panel.||Remain active, but are not visible or editable from the dashboard on which the alert is set unless self-assigned by another active user. Admins can edit or self-assign the alert from the Alerts management admin page in the Admin panel.|
|Historical usage information for the user||Kept||Most deleted|
If you need to stop user access to Looker, the best practice is typically to disable the user account. When you disable a user account, the user’s usage history and personal content is kept. For details about the differences between disabling and deleting users, see the table in the Removing User Access section.
To disable a user account, click the Disable button on the right-hand side of their row. A dialog box will ask you to confirm that you want to disable the user’s account.
Deleting a user is irreversible. Consider your organization’s compliance and security needs before doing so.
Instead of deleting, a great alternative is to disable the user account instead. This prevents a user from being able to log in, but their information, content, and history remain intact. For details about the differences between disabling and deleting users, see the table in the Removing User Access section.
To delete a user:
Click the Edit button on the right-hand side of their row.
At the bottom of the Edit User page, click Delete.
A dialog box will ask you to confirm that you want to delete the user’s account. Click OK to delete the user.
Impersonating (Sudoing) Users
“Sudo” is a Unix term that means to emulate the permissions of another user. Sudoing allows you to navigate Looker as if you are another user, with their privileges and abilities.
Only admins and users who have both the
sudo permissions have the ability to sudo as other users. Admins can sudo as any other user, including other admins. Users with the
sudo permissions can sudo as other non-admin users.
To sudo as another user, click the user’s Sudo button from the Users Admin page:
This is a good way to validate that you’ve properly configured permissions and other features. Sudoing is also a useful way to see a user’s LookML development before they’ve committed and pushed their changes.
When you sudo you’ll see a bar at the top of the screen that warns you that you’re in a sudoed state, and that enables you to exit the sudoed state. Any changes you make while in this state will impact the user you’re emulating.
Keep in mind that if you are in Development Mode, your changes are not visible to other users until you deploy your changes to production. If you haven’t deployed your changes for other users to see, you will not see your changes when you sudo as a different user.
For database connections that use OAuth, such as Snowflake and Google BigQuery, an admin sudoing as another user will use the sudoed user’s OAuth access token when running queries. For Snowflake connections, if the user’s access token is expired, the admin will not be able to have a new token created on behalf of the sudoed user; the user will have to log in to Snowflake and reauthorize Looker.