Skip to main content
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. If the card says SCIM is set up and managed in the setup wizard, use SCIM Provisioning.
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. 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 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 and Okta.
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.
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.
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:
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.
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. If First user ready to sign in stays Waiting or Blocked, open the Health tab. See 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.
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.
7

Send one group

Assign one small group to the app and send it from your IdP.
First group received shows Done, and the group appears as a directory group. See Groups and cohorts.
8

Test a deactivation

Unassign or disable the test person in your IdP, and send the change.
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. 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 to 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, 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.

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.