> ## 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. # SCIM user lifecycle > What Living Security SCIM does when your identity provider creates, updates, deactivates, reactivates or deletes a person, and why a change can be held. > [!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). 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](https://docs.livingsecurity.com/features/settings/scim/sso-and-sub-organizations.md#identity-requirements). * **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](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1107)). More than one primary email returns `400` ([LS-SCIM-1108](https://docs.livingsecurity.com/features/settings/scim/errors.md#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](#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](#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**: | Source | Attributes | | - | - | | Core user | `userName`, `externalId`, `displayName`, `nickName`, `title`, `userType`, `preferredLanguage`, `locale`, `timezone`, `name` (given, family and middle names, prefix and suffix), `emails`, `phoneNumbers`, `addresses` | | Enterprise extension (`urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`) | `employeeNumber`, `costCenter`, `organization`, `division`, `department`, `manager` | | Living Security extension (`urn:ietf:params:scim:schemas:extension:livingsecurity:2.0:User`) | `startDate` (`YYYY-MM-DD`), `location`, `employmentType` | * `manager.value` is the manager's SCIM user `id`, not their email. * The [SCIM attribute reference](https://docs.livingsecurity.com/features/settings/scim/attributes.md) 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](#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**. | Reason | Code | What to do | | - | - | - | | **Last owner** | [LS-SCIM-1501](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1501) | The change would deactivate or remove your organization's last owner. Make another person an owner, then send the change again from your IdP. | | **Excluded from directory sync** | [LS-SCIM-1502](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1502) | An admin excluded this person from sync. Profile and email changes are not applied. Deactivation and delete still apply. Remove the exclusion if your IdP should manage the person. | | **Matches more than one person** | [LS-SCIM-1503](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1503) | Merge or correct the duplicate person records, then send the change again from your IdP. | | Sign-in account waits on a conflict | none | The person's email already belongs to a sign-in account elsewhere. Living Security does not create a second account for the same email. Contact Living Security support. | > [!TIP] > > Assign at least two owners before you turn on provisioning, so the last-owner rule never holds a change. ## Timing | What | When | | - | - | | Response to your IdP | At once. The change is saved before the response. | | Deactivation and delete in Living Security | In the same request. | | New people, profile changes and sign-in accounts | Usually within a minute. A large first sync can take several minutes. | | Sign-in account changes when the sign-in service is briefly unavailable | Retried automatically. The saved change is not lost. | 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. ## Related * [Groups and cohorts](https://docs.livingsecurity.com/features/settings/scim/groups.md) * [SSO, multiple connections and sub-organizations](https://docs.livingsecurity.com/features/settings/scim/sso-and-sub-organizations.md) * [API reference and limits](https://docs.livingsecurity.com/features/settings/scim/api-reference.md) * [SCIM error reference](https://docs.livingsecurity.com/features/settings/scim/errors.md) ## Related topics - [SCIM groups and cohorts](https://docs.livingsecurity.com/features/settings/scim/groups.md) - [SCIM attribute reference](https://docs.livingsecurity.com/features/settings/scim/attributes.md) - [SCIM API reference and limits](https://docs.livingsecurity.com/features/settings/scim/api-reference.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.