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.
This page describes what happens to a person in Living Security when your identity provider (IdP) sends each kind of SCIM change.

Create

Your IdP creates a person with POST /Users.
  • userName is required and must be unique in your organization. Case does not matter: Alex@Example.com and alex@example.com are the same userName. Use the person’s email address. See SSO and sub-organizations.
  • An active person needs one usable email. Living Security takes the email marked "primary": true. Without one, it takes the first work email, then the first email, then a userName that is an email address. We recommend one email marked primary. A request with no usable email returns 400 (LS-SCIM-1107). More than one primary email returns 400 (LS-SCIM-1108).
  • An inactive user creates no person. A user created with "active": false is stored for your IdP but creates no person in Workforce → People. If it has a usable email, Living Security creates a disabled sign-in account. Without a usable email, the sign-in account waits. Some IdPs create disabled accounts before the mailbox exists. The person is created when your IdP sets active to true, and that request needs a usable email.
  • externalId need not be unique. Two people can have the same externalId.
For an active user, Living Security then creates the person in Workforce → People and their sign-in account. The SCIM response is immediate. The person usually appears within a minute.

People who already exist

When your IdP creates a person whose email already belongs to someone in your organization, Living Security links the SCIM user to that person. The person keeps their roles, training and history. No duplicate is created. The same applies to sign-in accounts. When the person already has a sign-in account in your organization for the same userName, for example one that the earlier SCIM setup made, Living Security uses that account. The person signs in as before. An account that also belongs to another Living Security organization is not reused: the change is held as Sign-in account waits on a conflict (see Held changes). One exception: an owner or admin who already signs in with a different account is not linked automatically. The change is held as Matches more than one person. See Held changes.

Welcome email

New people get a welcome email only when Send welcome email when SCIM provisions a new user is on in your SCIM settings. It is off by default. The email goes out once, when the person is first created. A reactivation does not send it again.

Update

Your IdP updates a person with PUT (replace the whole user) or PATCH (change some attributes).
  • With PUT, an attribute your IdP leaves out is cleared. This is what the SCIM standard requires.
  • Living Security keeps every attribute your IdP sends. These attributes update the person in Workforce → People:
  • manager.value is the manager’s SCIM user id, not their email.
  • The SCIM attribute reference lists every attribute and what it updates.
  • Other extension schemas are stored and returned to your IdP, but they do not update the person’s profile.
  • SCIM roles and entitlements never grant roles or access in Living Security.
  • Admin overrides win. When an admin edits a value on the person in Living Security, later SCIM updates do not replace it until the admin resets that value.

Email changes

When the primary email changes, the person’s profile takes the new email at once. The old email keeps working for sign-in for a transition window of about 24 hours, so the person is not signed out while the change reaches their sign-in account.

userName changes

The userName is the person’s login name. In an organization with SSO, a new userName replaces the old login name: the person must then sign in with SSO sending the new value as the NameID. Change userName only together with the SSO NameID. In an organization without SSO, the person keeps signing in with their email address.

Deactivate and reactivate

Your IdP deactivates a person by setting active to false.
  • The person is deactivated in Living Security in the same request. Their access ends at once.
  • Their sign-in account is disabled. SSO and email sign-in are refused.
  • Their profile, training and history stay.
Setting active back to true reactivates the person and their sign-in account. A deactivation is not held for review. The last-owner rule is the only rule that can hold it. See Held changes.

Delete

Your IdP deletes a person with DELETE /Users/{id}.
  • The person is deactivated in Living Security and removed from every SCIM group. Their sign-in account is deleted, and existing sessions end.
  • GET /Users/{id} then returns 404, as the SCIM standard requires.
  • The userName is free at once, so your IdP can use it again.
  • Living Security keeps a hidden record of the deleted SCIM user for 90 days, then removes it.

Create the person again

If your IdP creates the person again after a delete, Living Security links the new SCIM user to the same person by email. Their history stays. The new SCIM user gets a new id.

Held changes

Some changes are saved but not applied to the person. Your IdP still gets a success response, so it does not stop provisioning or quarantine the app. The SCIM card shows the count in Held accounts, and Troubleshoot SCIM → Health lists each reason under Why accounts are held.
Assign at least two owners before you turn on provisioning, so the last-owner rule never holds a change.

Timing

Your IdP decides when it sends changes. Microsoft Entra ID sends them in provisioning cycles, usually every 40 minutes. Okta sends most changes when they happen.