> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloud.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SCIM Troubleshooting

> Common problems when provisioning users and groups to Connect AI with SCIM, with suggested solutions and the details to gather before contacting support.

Use this page to diagnose problems with [SCIM Users](https://docs.cloud.cdata.com/en/SCIM/SCIM-Users.md) and [SCIM Groups](https://docs.cloud.cdata.com/en/SCIM/SCIM-Groups.md) provisioning. Each problem lists likely causes and solutions. Start with the section that matches the symptom you see in your identity provider (IdP).

> [!NOTE]
>
> Connect AI uses Auth0 as its managed identity broker. Any step that refers to the Auth0 tenant, connection, or logs is handled by CData on the broker side and is not something you configure yourself. If one applies to your issue, contact [CData Support](https://www.cdata.com/support/submit.aspx). The remaining steps are configured in your IdP.

## Authentication Errors

> **Test Connection fails or the IdP reports 401 Unauthorized.**
>
> The IdP could not authenticate to the SCIM endpoint. Check for any of the following:
>
> * The token is incorrect. Enter the Bearer token exactly as it appeared in the self-service session, with no leading or trailing spaces and no added `Bearer` prefix.
> * The token belongs to a different Connect AI account than the SCIM endpoint URL. The URL and token are a matched pair.
> * The token was replaced or revoked. Contact [CData Support](https://www.cdata.com/support/submit.aspx) to confirm that the token is still valid. To receive a new token, see [Obtaining Your SCIM or SSO Credentials](https://docs.cloud.cdata.com/en/SCIM/SCIM-Users.md#obtaining-your-scim-or-sso-credentials).
>
> After you correct the token, run the connection test again.

> **Test Connection fails or the IdP reports 404 Not Found.**
>
> The IdP could not reach the SCIM endpoint. Check for any of the following:
>
> * The URL is not the SCIM endpoint from the self-service session. The URL follows the format `https://<your-domain.com>/scim/v2`.
> * *(Entra ID)* The Tenant URL is missing `?aadOptscim062020` at the end.
> * *(Okta)* The **SCIM 2.0 Base URL** has a trailing slash. Remove it.
> * The URL has a typo or extra characters, for example from copying it incorrectly.

> **The Get Started button is unavailable, or automatic provisioning cannot be selected in Entra ID.**
>
> * Connect AI does not appear in the Entra application gallery. Create a new non-gallery application and configure provisioning on that application. See [SCIM Users](https://docs.cloud.cdata.com/en/SCIM/SCIM-Users.md).
> * Automated provisioning requires Microsoft Entra ID Premium P1 or P2. Organizations on the Entra ID free tier cannot configure it.

> **The self-service link expired, was already used, or the session ended before I finished.**
>
> The link works only once and is time-limited. If you opened it before you were ready, it expired, or the session ended, you cannot reuse it. Contact [CData Support](https://www.cdata.com/support/submit.aspx) for a new link, and complete the preparation steps in [Obtaining Your SCIM or SSO Credentials](https://docs.cloud.cdata.com/en/SCIM/SCIM-Users.md#obtaining-your-scim-or-sso-credentials) first.

> **SCIM is not available for my account.**
>
> SSO must be configured, and CData Support must enable SCIM Users, SCIM Groups, or both, before you can connect your IdP. Contact [CData Support](https://www.cdata.com/support/submit.aspx) to confirm the status of your account.

## Users or Groups Not Provisioning

> **Users do not appear in Connect AI.**
>
> Check for any of the following:
>
> * *(Entra ID)* The users are not assigned to the application. Assign them, or assign a group that contains them, under **Users and groups**.
> * *(Entra ID)* **Provisioning Status** is not set to **On**.
> * *(Okta)* **Create Users**, **Update User Attributes**, and **Deactivate Users** are not all enabled under **Provisioning to App**.
> * *(Okta)* The users are not assigned to the SCIM application on the **Assignments** tab.
> * The IdP has not run a provisioning cycle yet. Use **Provision on demand** in Entra ID to test a single user and see the result immediately.

> **Groups do not appear in Connect AI.**
>
> * *(Okta)* Assigning a group to the SCIM application does not push it. You must also select the **Push Groups** tab and push each group. This step is separate from **Assignments**.
> * *(Entra ID)* Confirm that **Provision Entra ID Groups** is set to **Enabled** under **Mappings**.
> * SCIM Groups must be enabled on your account. See [SCIM Groups](https://docs.cloud.cdata.com/en/SCIM/SCIM-Groups.md).

> **A provisioned user cannot sign in.**
>
> * *(Okta)* You must assign the same users and groups to both the SCIM application and your SSO application. If a user or group is assigned only to the SCIM application, the user is provisioned but cannot sign in with SSO. Okta group rules automate group membership, but they do not assign the group to each application.
> * Confirm that SSO is configured and working for the user's email domain. See [User Provisioning and SSO](https://docs.cloud.cdata.com/en/SCIM.md).
> * Just-in-Time (JIT) provisioning is not available for accounts that use SCIM.

> **Users in a group have no access to connections.**
>
> Groups synced from your IdP do not receive roles automatically. After the group appears in Connect AI, assign access roles to it on the **Groups** tab of the **Identities** page. See [Access Role Assignments](https://docs.cloud.cdata.com/en/SCIM/SCIM-Groups.md#access-role-assignments).

> **A user removed in the IdP still has access.**
>
> Removing a user from a synced group removes only the roles that came from that group. The user keeps access through other synced groups, direct role assignments, direct resource permissions, and personal access tokens (PATs). To fully deprovision the user, remove them from all synced groups in your IdP and then call `DELETE /users/{id}` from the Management API. See [SCIM Users](https://docs.cloud.cdata.com/en/SCIM/SCIM-Users.md#roles-and-permissions).

> **I cannot edit or delete a user or group in Connect AI.**
>
> Manage SCIM user profiles and group membership in your IdP. Create, update, and delete synced groups there as well. You can still change a user's system role on the **Users** tab and assign access roles to groups on the **Groups** tab. Name fields on SCIM-provisioned users cannot be changed through the Management API. To fully deprovision a user, follow [SCIM Users](https://docs.cloud.cdata.com/en/SCIM/SCIM-Users.md#roles-and-permissions).

## Attribute Mapping Issues

> **Provisioning fails with a conflict or 'resource already exists' error.**
>
> The user already exists in Connect AI, for example because they were invited by email before SCIM was enabled, and the IdP cannot match the existing record. Check for either of the following:
>
> * *(Entra ID)* On the **Users** tab of **Attribute Mapping**, the row that maps `mail` to `emails[type eq "work"].value` must have **Match objects using this attribute** set to **Yes** and **Matching precedence** set to **2**.
> * The matching attribute is the user's email address, and it is spelled identically in the IdP and in Connect AI.
>
> If the error persists, contact [CData Support](https://www.cdata.com/support/submit.aspx).

> **The email address is empty or incorrect on provisioned users.**
>
> *(Entra ID)* If users do not have the `mail` attribute populated, change **Source attribute** to `userPrincipalName` in the same mapping row. This ensures that the email field is always populated.

> **Updates to users fail or are ignored (Okta).**
>
> * Under **Attribute Mappings**, delete the **Primary email type**, **Primary phone type**, and **Address type** rows. These rows can cause problems during updates.
> * Confirm that **Update User Attributes** is enabled under **Provisioning to App**.

> **Group membership changes or deactivations in Okta are silently lost.**
>
> On SAML connections, the identifier that Okta uses for later update and delete requests can contain characters that are not valid in a URL. The requests then fail inside Okta before they are sent, and no error appears in Okta or in Connect AI. This occurs only when the Okta setting **Unique identifier field for users** is set to `id` instead of `userName`. Set it to `userName`. If the problem continues, contact [CData Support](https://www.cdata.com/support/submit.aspx), because the matching change is on the broker side.

## Verifying What the IdP Sends and What Connect AI Receives

When the cause is not clear, compare the two sides for a single user or group. Use one test user and one test group, and note the exact time of each attempt.

**Step 1**

**Test Provisioning in the IdP.** In Entra ID, select **Provision on demand**, choose the user or group, and click **Provision**. The result lists each step and shows the attributes that Entra ID sent. In Okta, assign a new test user to the SCIM application on the **Assignments** tab, or push a new test group from **Push Groups**. Check the resulting provisioning event in the **System Log**. **Test API Credentials** checks the endpoint and token only; it does not provision a user or group.

**Step 2**

**Review the IdP logs.** In Entra ID, open the application, then **Provisioning logs**, and filter by the user's name or by status. Open an entry to see the request, the response, and the error text. In Okta, open **Reports** > **System Log** and filter on the application name and the user's email address.

**Step 3**

**Review the Audit Log in Connect AI.** Open **Logs** > **Audit Log**, set the **Date Range** around the time of your test, and filter by **Event Type** or **User**. Click an entry to expand its details. SCIM user provisioning, updates, and deletions appear here, as do group provisioning, membership changes, and role assignment changes. See [Logs](https://docs.cloud.cdata.com/en/Logs.md#audit-log).

**Step 4**

**Compare the results.** Use the following table to decide where the problem is.

| IdP log shows | Connect AI Audit Log shows | Likely cause |
| - | - | - |
| An error such as 401 or 404 | No entry | The request did not reach Connect AI. Check the token and URL. |
| Success | An entry for the event | Provisioning worked. Check roles, SSO assignment, and group role assignments. |
| Success | No entry | Contact CData Support with the timestamp and the user or group name. |
| No entry | No entry | The IdP did not attempt provisioning. Check assignments, the provisioning status, and **Push Groups** in Okta. |

> [!NOTE]
>
> The Audit Log records changes that Connect AI processes. Requests that are rejected before processing, such as those with an invalid token, might not appear in it. Use the IdP logs to diagnose those.

## Gathering Information for Support

If you cannot resolve the problem, contact [CData Support](https://www.cdata.com/support/submit.aspx) and include the following:

* **Account**–the Connect AI account name and the SCIM endpoint URL, without the token. Never send the Bearer token.
* **IdP**–Entra ID, Okta, or another provider, and whether the SSO connection uses SAML or OpenID Connect.
* **Scope**–whether the problem affects SCIM Users, SCIM Groups, or both, and whether it affects one user or group or many.
* **Example**–the email address of one affected user, or the name of one affected group.
* **Timestamp**–the date, time, and time zone of the most recent failed attempt.
* **IdP log entry**–the provisioning log or System Log entry for the failed attempt, including the full error text.
* **Audit Log entry**–a screenshot of the matching Connect AI Audit Log entry, or a note that none exists.
* **Recent changes**–any changes to attribute mappings, assignments, or the IdP application, and whether provisioning ever worked.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.