Skip to main content

​
After this article

You will be able to connect Looker to Lumos to sync users, their roles, and last-login activity, and to provision Looker users from Lumos. Provisioning covers creating users, assigning and removing roles, suspending, reactivating, and deprovisioning.

​
Capabilities

Provisioning behavior:
  • Create: Lumos first searches Looker for the email. If a matching user already exists, Lumos links that account instead of creating a duplicate. New users are created enabled.
  • Assign or remove a role: Lumos reads the user’s current roles and writes the updated set. Assigning a role the user already has, or removing one they don’t, is a safe no-op.
  • Reactivate: Lumos re-enables a suspended user by clearing the is_disabled flag.
Account status mapping:
  • Not disabled and able to log in outside the embedded user flow maps to Active
  • Disabled, or only able to log in as an embedded user, maps to Suspended
  • Deleted (Looker no longer returns the user) maps to Deprovisioned
Lumos uses the is_disabled flag and checks for credentials other than embed_credentials. Last Login: Looker records a logged_in_at per authentication method (API, email, Google, SAML). Lumos shows the most recent one across all methods.

​
Required plan and roles

  • Looker plan: no minimum plan required.
  • Looker role: the connecting Looker user must be an Admin.
  • Credential model: Lumos authenticates with an API key (Client ID + Client Secret) created on a Looker user. API keys are always bound to a Looker user: API requests execute as that user and only return or modify data that user can see and modify. If this is a concern, create the API key on a dedicated service account with Admin access.
  • Permission scoping: the same credential is used for sync and for all provisioning write actions. There is no separate read-only credential documented.

​
Read-only access vs provisioning

Is read-only possible? No. The same Admin-created API key is used for both sync and the provisioning write actions, and there is no separate read-only credential documented. What full provisioning requires. An API key (Client ID and Client Secret) created on an Admin user in Looker, ideally a dedicated service account so the key’s visibility isn’t limited by an individual’s own permissions. Follow the steps below. This connector supports the full account lifecycle: create users, assign and remove roles, suspend, reactivate, and delete. Watch out for. API keys execute as the Looker user they belong to, so if that user’s own permissions are reduced, Lumos only sees what they can see, use a dedicated Admin service account to avoid a partial sync. Deprovision permanently deletes a user’s data, including their Looks, so transfer content first or use Suspend instead if you need to preserve it.

​
Instructions

Phase 1: Create an API key in Looker
  1. In your Looker instance, go to the Admin section, then the Users page.
  2. On the (service account) admin user, create an API key. This generates a Client ID and Client Secret. Copy both.
  3. Note your Looker Host URL (e.g. https://example.cloud.looker.com) and, if different, your API Host URL.
Phase 2: Connect in Lumos
  1. Click the Looker card in your Lumos integrations (reconnect an existing card or add a new one).
  2. Looker Instance URL: the Host URL with the scheme removed. https://example.cloud.looker.com is entered as example.cloud.looker.com.
  3. Looker API URL: the API Host URL with the scheme removed. If left empty, Lumos assumes the API Host URL is the same as the Host URL.
  4. Looker Client ID and Looker Client Secret: from the API key created in Phase 1.
  5. Click Connect Looker.

​
API Endpoints Used

​
Troubleshooting

Can’t connect. Enter the Looker URLs into Lumos without the http:// or https:// prefix, and confirm the connecting Looker user is an Admin. Sync returns fewer users or roles than expected. API keys execute as the user they belong to. If that user’s permissions were reduced, Lumos only sees what they can see. Use a dedicated Admin service account for the API key. Deprovisioned user’s dashboards disappeared. Deprovision permanently deletes the user’s data, including their Looks. This is not reversible. For future offboarding, transfer content before deleting or use Suspend, which retains personal content while blocking login. Embed-only users show as Suspended. This is expected. Users who can only log in through the embedded user flow are mapped to Suspended in Lumos.