Metabase SCIM provisioning with Okta and Entra ID

The identity provider decides who is active, and Metabase follows it. Okta or Microsoft Entra ID sends SCIM requests to the Metabase endpoint at /api/ee/scim/v2 when a user is created, changed or deactivated. Metabase applies each request to its user records. A create request adds an account, an update request changes the profile fields the provider sends, and a deactivate request deactivates the matching Metabase account. The practical result is that a leaver loses access when the provider deactivates them, without a separate step inside Metabase. Before go-live, confirm which attribute the provider uses as the unique identifier for each user, and check that it matches the identifier Metabase stores for any existing accounts.

Group membership follows the same path. With Okta, pushed groups are created in Metabase and their members are populated from the provider, so group membership in Okta becomes group membership in Metabase. Because Metabase groups carry permissions, a change in the provider changes what a person can see after the next sync. Removing someone from a pushed group, or deactivating them, removes that access. Decide early which Okta groups should be pushed, because only those groups will be created in Metabase and only they will drive access from the provider. Check the group names, and identify any Metabase-only groups that the provider does not manage, since a provider sync may leave those memberships untouched. Confirm how Entra ID group pushes behave in your tenant and Metabase version before relying on them.

Two settings can surprise a team at cutover. SCIM requires a Pro or Enterprise plan, and enabling it disables SAML user provisioning, so accounts that depended on SAML to be created at first sign-in will no longer be created that way. Plan how existing users will be matched to provider identities, and decide whether to keep any local accounts for break-glass administration. Local accounts sit outside the provider, so their deactivation is a manual step that belongs in your access review. Review the list of existing accounts before the first sync, so that people who should not remain active are identified and handled before the provider takes over.

Verify the full chain on a non-production instance before the first production sync. Create a test user in the provider, confirm the account appears in Metabase with the expected group memberships, then deactivate the user in the provider and confirm the Metabase account is deactivated. Repeat the test by removing the user from a pushed group. Measure how long each change takes to appear in Metabase during your own test, because provider push schedules vary by configuration. Confirm the authentication mode for the Okta connection, which the supported setup documents as HTTP Header, and confirm the equivalent settings for Entra ID in your environment. Keep the test records, since they become your evidence that a leaver's access ended.

When SCIM is enabled in Metabase, SAML user provisioning is always disabled. That single rule shapes the design. Your team cannot let SAML create accounts on first sign-in while SCIM manages the account lifecycle from Okta or Microsoft Entra ID, so the first decision is which mechanism creates and deactivates users and which one authenticates them. Metabase's SCIM provisioning is available only on Pro and Enterprise plans, so the plan choice and the sign-in design should be made together. Settle both before you configure the identity provider, because changing the sign-in method later affects every user who signs in through it.

Sign-in options depend on the plan. On Pro or Enterprise, Metabase documents SAML setups for Auth0, Entra ID, Google, Keycloak and Okta, and also offers JWT, OIDC and advanced LDAP group and attribute sync. Open Source and Starter support Google sign-in and LDAP, while SAML, JWT, OIDC, advanced LDAP sync and SCIM provisioning require Pro or Enterprise. If your identity provider is Okta or Entra ID and you want SCIM, the practical shortlist is a Pro or Enterprise plan paired with a sign-in method you can test end to end. Confirm with Metabase which combinations are supported on your plan, since each feature is documented on its own.

Okta and Entra ID need separate planning. Metabase's SCIM support covers user and group provisioning with Okta, including creating and populating groups in Metabase, and it uses HTTP Header authentication mode for that connection. Check how that authentication mode fits with the sign-in method you chose, and decide which identity provider groups map to Metabase groups that carry permissions. Groups drive what users can see, so a mapping error can grant access as easily as it removes it. Entra ID is an officially supported SCIM target, so the same design questions apply, but confirm the exact application setup and attribute mappings against Metabase's current user provisioning guide before you build them.

Login setup is covered on the separate Keycloak SAML page, so this section does not repeat those steps. Read that page when SAML is your chosen method, and remember that SCIM still controls account creation and deactivation. Before production, build a test tenant and run the sign-in path your users will use. Confirm three things: a new user created in the identity provider appears in Metabase, a user deactivated in the identity provider can no longer sign in, and an account that existed before SCIM was enabled behaves as you expect. Record what you observe, because the test results become evidence for your access reviews.

Plan cost alongside the design. Metabase's pricing page lists Pro at $575 per month or $517.50 per month billed yearly, with the first 10 users included and $12 per month for each additional user. These are list figures from that page and they recur with the subscription, so ask for a current quote and confirm how users are counted for your team. Your next steps are to choose the plan, pick one sign-in method, assign an owner for the identity provider group to Metabase group mapping, and schedule the test tenant run before anything reaches production.

The test plan should prove three lifecycle events before any production user depends on the connection: a joiner receives an account and the right group, a mover's changes flow through, and a leaver cannot sign in. Run every step in a non-production Metabase instance on the Pro or Enterprise plan, because SCIM provisioning is available only on those plans. Use a pilot user and a pilot group in Okta or Microsoft Entra ID that no production person belongs to, and keep a written log of each action, when it was taken, and what Metabase showed afterward. Before the first step, confirm that SCIM is enabled in the test instance, that the identity provider's provisioning settings point at the Metabase SCIM endpoint, and that the authentication mode matches Metabase's documentation for your identity provider. For Okta, the documented setup uses HTTP Header authentication mode, so confirm that in your own build.

Start with the joiner. Create the pilot user in the identity provider, populate the attributes Metabase needs, such as name and email, and assign the user to the pilot group. Then open the people and groups pages in the Metabase admin console and confirm three things: the account exists with the expected name and email, the account belongs to the Metabase group that matches the pilot group, and the user can sign in through the configured single sign-on path. For Okta, confirm that the group itself was created and populated in Metabase, since that is the documented behavior for Okta group provisioning. For Entra ID, check group creation and membership against the provisioning logs in your own tenant, because the behavior you observe in that tenant is the result that counts. Also confirm that no second account exists for the same person from an earlier manual setup.

Next, test the mover. Change one attribute the connector maps, such as the display name, and confirm the Metabase account reflects the change after the next sync. Then move the pilot user from the pilot group to a second test group. Confirm that the old group membership is removed in Metabase and that the user's effective access changes. Test access, not only membership. Sign in as the pilot user and record which collections, databases and dashboards are visible before and after the move, because group membership matters only where it grants data permissions. If an attribute never updates, treat it as a mapping gap to investigate in the identity provider's attribute settings, and confirm the expected behavior in the vendor and Metabase documentation before you accept the result.

Finish with the leaver. Deactivate the pilot user in the identity provider, wait for the sync to reach Metabase, and confirm the Metabase account is deactivated. Then attempt a sign-in with the pilot user's credentials and confirm that it fails. Also check any browser session the user already had open, along with any API key or other credential tied to that account, and record how your Metabase version handles each one. Keep the joiner, mover and leaver tests as a regression set for every Metabase upgrade. Before each upgrade, back up the application database first, because the upgrade runs database migrations automatically and a pre-upgrade backup is the recommended rollback path. Follow the upgrading guide for the steps and the version order, then rerun all three tests on the upgraded instance before approving the production change.