Looker User Management Guide

• Model type: hybrid
• Description: Looker uses a hybrid model combining Roles (which bundle a Permission Set and a Model Set) assigned to users or groups. Permission Sets define what actions a user can perform (e.g., explore, develop, manage_users). Model Sets define which LookML models a user can access. Roles can be built-in or custom. Users can hold multiple roles simultaneously, and permissions are additive.
• Custom roles: Yes
• Custom roles plan: Available on all Looker plans; custom roles are created by combining custom or built-in Permission Sets with Model Sets in the Admin panel.
• Granularity: Granular: ~50+ individual permissions available in Permission Sets (e.g., see_looks, explore, develop, deploy, manage_users, access_data, download_with_limit, etc.). Model-level access is separately controlled via Model Sets.

1. Log in as an Admin and navigate to Admin > Users.
2. Click 'Add Users' button.
3. Enter one or more email addresses in the email field (comma-separated for multiple users).
4. Select the Roles to assign to the new user(s).
5. Optionally assign the user(s) to one or more Groups.
6. Choose whether to send a setup email to the new user(s).
7. Click 'Add' to create the user account(s).

Required fields: Email address

Watch out for:

• Users are created with 'No Authentication' by default if SSO/LDAP is not configured; they must set a password via the setup email.
• If SAML or OIDC SSO is enabled, users may be auto-provisioned on first login, but pre-creating them in the Admin panel is still possible.
• Role assignment at user creation is optional but recommended; users without roles have no meaningful access.
• Adding users does not automatically consume a license seat in all configurations - confirm seat counting with your Google Cloud contract terms.
• There is no native CSV import in the UI; bulk creation requires use of the Looker API.

• Can delete users: Verify in tenant
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Navigate to Admin > Users.
2. Locate the user by searching their name or email.
3. Click 'Edit' next to the user.
4. Click the 'Disable' (or 'Deactivate') button on the user's profile page.
5. Confirm the action. The user's status changes to 'Disabled' and they can no longer log in.

Watch out for:

• Scheduled plans (email deliveries, webhooks) owned by a deactivated user stop immediately; they must be reassigned to another user before deactivation to avoid disruption.
• API keys associated with a deactivated user are also disabled, which can break integrations or scripts using that user's API credentials.
• Permanent deletion via API removes all user data including API keys and credentials but does NOT automatically reassign or delete owned content - orphaned content may become unmanageable.
• There is no bulk deactivation option in the Admin UI; deactivation must be done one user at a time in the UI, or in bulk via the Looker API.
• SSO-provisioned users who are removed from the IdP will be unable to log in via SSO, but their Looker account record remains active until manually deactivated in Looker.

• Where to check usage: Admin > Users (filter by 'Active' status to see active seat count). Also available via Looker API: GET /users with filters. System Activity Explores (if enabled) provide last-login and usage data.
• How to identify unused seats: Use Admin > Users and sort or filter by 'Last Login' date. Alternatively, query the System Activity 'User' Explore (if System Activity is enabled on your instance) to find users with no login activity in a defined period. The Looker API endpoint GET /users also returns last_login timestamps.
• Billing notes: Looker is sold under annual contracts with custom pricing negotiated with Google Cloud sales. There is no self-serve billing portal for seat management. Seat additions mid-contract may require a contract amendment. Looker Studio Pro ($9/user/month) is a completely separate product from Looker (the enterprise BI platform) and is not interchangeable.

Looker is sold under annual contracts with custom pricing negotiated through Google Cloud sales. There is no self-serve billing portal, and seat additions mid-contract may require a contract amendment. Developer seats are typically the most expensive tier; confirm seat-type definitions with your Google Cloud agreement before provisioning.

Scheduled deliveries owned by a deactivated user stop immediately without warning. Admins must manually reassign those scheduled plans before deactivating the user, or downstream consumers lose their reports with no automated fallback.

SSO-provisioned users removed from the IdP are not automatically deactivated in Looker - their account record stays active until an admin manually disables it, creating a real access-control gap at offboarding.

The most consistent friction reported by Looker admins centers on three areas: the absence of native SCIM, the one-at-a-time deactivation constraint in the UI, and the opacity of seat pricing.

The open-source looker-scim-proxy exists on GitHub as a community workaround, but it is not officially supported by Google Cloud and requires self-hosting and ongoing maintenance. Admins who rely on it accept the risk that it may lag behind Looker API changes.

Bulk user creation and bulk deactivation both require API scripting - there is no UI shortcut for either operation.

Common complaints:

• No native SCIM support; the open-source looker-scim-proxy is not officially supported by Google Cloud and requires self-hosting and maintenance.
• No bulk deactivation in the Admin UI; admins must deactivate users one at a time or script via API.
• No native CSV import for bulk user creation in the UI; bulk operations require API scripting.
• Scheduled deliveries owned by deactivated users stop without warning and must be manually reassigned beforehand.
• SSO-provisioned users removed from the IdP are not automatically deactivated in Looker; manual cleanup is required.
• Seat pricing is opaque and requires direct engagement with Google Cloud sales; no self-serve tier or public per-seat pricing.
• Content ownership is not automatically transferred when a user is deactivated, leading to orphaned Looks and dashboards.
• Must rely on Google Cloud Identity or SAML/OIDC for automated provisioning; no native Okta or Entra SCIM connector.

Use the Admin UI for low-volume, ad hoc user changes: adding a single user, adjusting a role, or disabling one departing employee. The UI is sufficient for teams with infrequent user churn and a small roster.

Switch to API-based management when you need bulk provisioning, bulk deactivation, or any repeatable sync against an external directory. The UI does not scale to those workflows. If your organization requires SCIM-based provisioning from an IdP, evaluate the community looker-scim-proxy carefully - its unsupported status is a real operational risk, not a minor caveat.

Bottom line

Looker's manual user management works for small, stable teams but breaks down quickly at scale. No native SCIM, no bulk UI operations, and no automatic IdP-driven deactivation mean that every app access review or offboarding event requires deliberate admin action.

Teams managing more than a handful of users should plan for API automation from the start, and anyone evaluating SCIM integration should treat the community proxy as a stopgap rather than a supported solution.