> For the complete documentation index, see [llms.txt](https://docs.carto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.carto.com/carto-user-manual/settings/users-and-groups/scim-provisioning.md). # SCIM provisioning **SCIM** (System for Cross-domain Identity Management) lets your Identity Provider (IdP) push group and membership changes, and user deletions, to CARTO as they happen. Your IdP notifies CARTO directly, so group moves and leavers are reflected in your organization without waiting for the affected users to log in. New users still join CARTO on their first SSO login. {% hint style="info" %} SCIM provisioning is only available for **Enterprise Large** plans and above, and requires an existing [SSO integration](/carto-user-manual/settings/sso.md). Please get in touch at if you're interested in this feature. {% endhint %} ## Why SCIM Without SCIM, CARTO reads a user's group membership from your IdP each time that user logs in, so changes only land when the affected user next signs in. Someone moved into a new group keeps their old access until their next login, and someone removed from a group keeps that group's access until then too. Pushing changes instead matters most for: * **Offboarding.** A user deleted in your IdP is removed from CARTO right away, not at their next login attempt. CARTO acts on user deletions only, so check what your IdP sends when you unassign a user (see the table below). * **Role changes.** When you use [group role mapping](/carto-user-manual/settings/users-and-groups/mapping-groups-to-user-roles.md), a move between groups applies the new role right away. * **Onboarding.** Groups exist in CARTO before anyone logs in, so you can assign roles to them ahead of time. Users are created in CARTO on their first SSO login, and any group memberships your IdP sent before then are applied at that login. * **Audit.** Group memberships in the *Users & Groups* settings follow your IdP as changes happen, which makes access reviews meaningful. ## What SCIM keeps in sync Once SCIM is enabled, your IdP becomes the source of truth for users and groups in CARTO: | Change in your IdP | Result in CARTO | | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A user is assigned to CARTO | Nothing yet. The user is created in CARTO on their first SSO login, with the **Default role** set in the *Users & Groups* settings (see [Managing user roles](/carto-user-manual/settings/users-and-groups/managing-user-roles.md)), or with the role granted by their groups if you use [group role mapping](/carto-user-manual/settings/users-and-groups/mapping-groups-to-user-roles.md). Group memberships sent before that login are applied when the user is created | | A user's email address or profile is updated | Not synced. CARTO does not apply user profile changes received through SCIM | | A user is deactivated (`active: false`) | Not acted on by CARTO. The user stays in your organization; to remove them, delete the user in your IdP | | A user is added to or removed from a group | Their [group](/carto-user-manual/settings/users-and-groups/managing-user-groups.md) membership is updated, along with any role that group grants | | A group is created, renamed or deleted | The group is created, renamed or removed in the *Groups* tab of the *Users & Groups* settings | | A user is deleted in your IdP | The user is removed from your CARTO organization and can no longer log in. The resources they shared are transferred to an Admin of your organization | {% hint style="info" %} When SCIM is enabled, CARTO no longer reads group membership from your IdP at login. SCIM becomes the only source of group membership, so a membership change your IdP did not send is not picked up at the user's next login either. {% endhint %} ## Setting up SCIM Like SSO, SCIM integrations are handled by our Support Team. Get in touch at and mention that you want to enable SCIM provisioning, along with the IdP you use. Our Support Team will provide two values for you to configure in your IdP: * **SCIM endpoint URL:** the base URL your IdP sends provisioning requests to, unique to your organization. * **Secret token:** the bearer token your IdP uses to authenticate against that endpoint. CARTO implements the **SCIM 2.0** standard, exposing the `/Users` and `/Groups` resources, so any IdP with SCIM 2.0 support can integrate with it. ## Choosing which users and groups to sync Your IdP decides what to send to CARTO, so you scope the sync there rather than in CARTO. In most providers you assign the CARTO application to the users and groups that should exist in CARTO, and only those are provisioned. This replaces the need to [pre-create groups](/carto-user-manual/settings/users-and-groups/mapping-groups-to-user-roles.md#pre-creating-groups-for-role-mapping) for role mapping: groups arrive from your IdP with their members already populated, so you can assign roles to a group as soon as it appears. {% hint style="info" %} If you previously set up group sync rules for SSO, review them when you enable SCIM. Groups now arrive through the provisioning configuration of your IdP application, which may be scoped differently from your old SSO group claim. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.carto.com/carto-user-manual/settings/users-and-groups/scim-provisioning.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.