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

# Test your SCIM setup

> Check a Living Security SCIM connection before you provision everyone: the setup checklist, one test user, the dry run, the Entra mapping check, and what ready means.

> [!NOTE]
>
> **Which SCIM setup applies to you?** These pages describe **Living Security SCIM**. Open the SCIM card in your settings. If the card shows **Set up SCIM**, or its **Mode** row says **Native SCIM**, these pages apply. If **Mode** says **Current SCIM**, your organization still uses the earlier SCIM setup. An admin can move it: see [Move from the earlier SCIM setup](https://docs.livingsecurity.com/features/settings/scim/connection.md#move-from-the-earlier-scim-setup). If the card says SCIM is set up and managed in the setup wizard, use [SCIM Provisioning](https://docs.livingsecurity.com/features/settings/scim.md).

Test a SCIM connection with one person before your identity provider (IdP) provisions everyone. Living Security checks each step for you. You do not mark anything as done.

All the tools on this page are on the SCIM card: select **Troubleshoot SCIM**. They need the identity-provider permission.

## The setup checklist

The **Checklist** tab ticks each step from what Living Security has received. A later step proves the earlier ones, so a step can show **Done** without its own date.

| Step | Done when |
| - | - |
| **SCIM token created** | A token exists for the connection. |
| **First request received** | Your IdP sent any request with a valid token. |
| **Connection test passed** | Your IdP made a successful read, such as its connection test or a `GET` request. |
| **First user received** | Your IdP created one user. |
| **First user ready to sign in** | At least one person has a sign-in account. |
| **First sign-in by a SCIM user** | A person created by SCIM signed in. |
| **First group received** | Your IdP created one group. |
| **SSO login names match** | People who sign in with SSO land in the account SCIM created for them. |

Each step shows one of these states:

* **Done**: the step is complete.
* **Waiting**: nothing has happened yet. The step says what to do next in your IdP.
* **Blocked**: something stops the step. It shows the error code. For example, **First request received** is blocked with [LS-SCIM-1001](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1001) when no token is valid.
* **Not used**: the step does not apply. For example, **SSO login names match** is **Not used** when SCIM people sign in, but none of them with SSO.

## Test with one user

Follow these steps in order. They work for every SCIM 2.0 IdP. The IdP guides give the exact menu names: [Microsoft Entra ID](https://docs.livingsecurity.com/features/settings/scim-microsoft-entra-id.md) and [Okta](https://docs.livingsecurity.com/features/settings/scim-okta.md).

**1. Create the token**

On the SCIM card, select **Set up SCIM**, then copy the **SCIM base URL** and the **Bearer token** into your IdP. See [Set up a SCIM connection](https://docs.livingsecurity.com/features/settings/scim/connection.md).

> [!TIP]
>
> **SCIM token created** shows **Done**.

**2. Test the connection from your IdP**

Run your IdP's connection test. In Microsoft Entra ID, select **Test Connection** on the **Provisioning** page. In Okta, use the test button on the app's **Provisioning** tab. For an IdP without a test button, send one request, for example `GET /ServiceProviderConfig`.

> [!TIP]
>
> **First request received** and **Connection test passed** show **Done**.

If **First request received** stays **Waiting**, the request did not reach Living Security, or it went to another region's base URL. If your IdP reports `401`, copy the base URL and a current token from the SCIM card again.

**3. Check your mappings**

Before you send a real person:

* Use **Test a payload** on the **Validate** tab with a sample request. See [Dry run a request](#dry-run-a-request).
* If you use Microsoft Entra ID, use **Check an Entra mapping**. See [Check an Entra mapping](#check-an-entra-mapping).
* Compare your mappings with the [SCIM attribute reference](https://docs.livingsecurity.com/features/settings/scim/attributes.md).

**4. Provision one test user**

Assign one test person to the app in your IdP and send them:

* **Microsoft Entra ID:** select **Provision on demand**, choose the person, then select **Provision**.
* **Okta:** assign the person to the app. With **Create Users** on, Okta sends them at once.
* **Other IdPs:** assign the person to the app, then start a sync if your IdP has one.

Use a person whose email can receive mail. Turn off **Send welcome email when SCIM provisions a new user** first if the person should not get a welcome email.

> [!TIP]
>
> **First user received** shows **Done**. After a few minutes, **First user ready to sign in** shows **Done**.

If **First user received** is **Blocked**, read the code it shows in the [SCIM error reference](https://docs.livingsecurity.com/features/settings/scim/errors.md). If **First user ready to sign in** stays **Waiting** or **Blocked**, open the **Health** tab. See [Held changes](https://docs.livingsecurity.com/features/settings/scim/user-lifecycle.md#held-changes).

**5. Check what your IdP sent**

Open the **Attributes** tab.

* **What to fix** lists mapping problems, for example **User name is not an email address** or **Work email missing**. Each one says how to fix it in your IdP.
* **Attributes received** shows how many people have a value for each attribute Living Security reads.
* **Newest user** shows the values Living Security stored and the last request from your IdP.

Then open the person in **Workforce → People** and check their name, email, job title, department and manager.

**6. Sign in as the test user**

Ask the test person to sign in to Living Security, with SSO if your organization uses it.

> [!TIP]
>
> **First sign-in by a SCIM user** shows **Done**. With SSO, **SSO login names match** shows **Done**.

If the person signs in to a different account, **SSO login names match** is **Blocked**. Map `userName` to the same value your SSO sends as the NameID. See [SSO and sub-organizations](https://docs.livingsecurity.com/features/settings/scim/sso-and-sub-organizations.md).

**7. Send one group**

Assign one small group to the app and send it from your IdP.

> [!TIP]
>
> **First group received** shows **Done**, and the group appears as a directory group. See [Groups and cohorts](https://docs.livingsecurity.com/features/settings/scim/groups.md).

**8. Test a deactivation**

Unassign or disable the test person in your IdP, and send the change.

> [!TIP]
>
> The person shows as deactivated in **Workforce → People** and can no longer sign in. Assign them again to reactivate them.

## Dry run a request

**Validate → Test a payload** runs a SCIM request without saving it. Use it to see what a request from your IdP would do before your IdP sends it.

1. Choose the **Request**: `POST` creates a user, `PUT` replaces one, `PATCH` changes one.
2. For `PUT` or `PATCH`, enter the **SCIM user ID** of a stored user. Leave it empty on a `PATCH` to apply the operations to an empty user.
3. Paste the **SCIM body**, for example from your IdP's provisioning logs. The limit is 256 KiB.
4. Select **Run dry run**.

The result shows:

* The HTTP status your IdP would get, and **Nothing saved**.
* The changes to the person: each attribute with its value **Before** and **After**, and whether the person is created, deactivated or reactivated.
* The **Response to the identity provider**: the resource, or the SCIM error with its `LS-SCIM` code.

The dry run checks the SCIM request as a real request would, including a unique `userName`. It does not apply the rules that can hold a change on the person: an admin's manual edits, an exclusion from directory sync, and the last-owner rule. A dry run can show a profile change that the real request holds or that an admin edit keeps. See [Held changes](https://docs.livingsecurity.com/features/settings/scim/user-lifecycle.md#held-changes).

You can run a limited number of checks each minute. If you see **Too many checks in a minute**, wait a minute.

## Check an Entra mapping

**Validate → Check an Entra mapping** reads the attribute mappings of a Microsoft Entra ID enterprise application and finds problems before Entra sends anyone.

1. In Entra, open **Provisioning → Mappings → Show advanced options → Review your schema here**, and download the schema.
2. In Living Security, paste or upload the whole file. The limit is 256 KiB.
3. Enter the **Single sign-on NameID source**, for example `user.userprincipalname`.
4. Select **Check mapping**.

Each finding has a code from [LS-SCIM-1701](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1701) to [LS-SCIM-1707](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1707) and a fix. The check finds, for example, users matched on the wrong attribute, a `userName` that differs from the SSO NameID source, an `active` mapping that does not follow deletion, and a missing work email. Nothing is saved.

The mapping check reads Entra exports only. For other IdPs, provision one test user and use the **Attributes** tab.

## Preview mode

Living Security SCIM has no preview mode. A change applies when your IdP sends it. To limit the first sync, scope your IdP to one test person or a small group, as in [Test with one user](#test-with-one-user), and widen the scope after each check.

## What "ready" means

Your connection is ready to provision everyone when:

* Every checklist step shows **Done** or **Not used**.
* The **Health** tab shows **No warnings**.
* The **Attributes** tab shows no **What to fix** items, or only items you chose to accept.
* The test person has the profile you expect in **Workforce → People** and can sign in.

Then widen the scope in your IdP: a small group first, then everyone. Check the **Health** tab after each step. See [Security and best practices](https://docs.livingsecurity.com/features/settings/scim/security.md#best-practices).

## Ask for help

Select **Copy diagnostics** on the troubleshooting page and paste the result into your support request. It has connection IDs, request IDs and error codes. It never has names, email addresses or tokens.

## Related

* [SCIM attribute reference](https://docs.livingsecurity.com/features/settings/scim/attributes.md)
* [SCIM error reference](https://docs.livingsecurity.com/features/settings/scim/errors.md)
* [SCIM user lifecycle](https://docs.livingsecurity.com/features/settings/scim/user-lifecycle.md)
* [Set up a SCIM connection](https://docs.livingsecurity.com/features/settings/scim/connection.md)


## Related topics

- [Set up SCIM with another SCIM 2.0 client](https://docs.livingsecurity.com/features/settings/scim-generic.md)
- [SCIM and Google Workspace](https://docs.livingsecurity.com/features/settings/scim-google-workspace.md)
- [Set up SCIM with SailPoint](https://docs.livingsecurity.com/features/settings/scim-sailpoint.md)


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