---
title: "Automated user provisioning and de-provisioning (SCIM 2.0)"
description: "SCIM 2.0 connects your identity provider to Talkspirit, automating member account creation, updates, and deactivation."
category: administration-security
section: authentication-and-sso
tags: [admin]
type: Tutorial
lastUpdated: 2026-09-11
locale: en
canonical: https://support.talkspirit.com/en/administration-security/automated-user-provisioning-and-de-provisioning-scim-20
---

# Automated user provisioning and de-provisioning (SCIM 2.0)


SCIM 2.0 connects your identity provider (IdP) to Talkspirit so member accounts are created, updated, and deactivated automatically. You configure it under **Administration → Authentication → SCIM**: generate a provisioning token, then give that token and your SCIM endpoint to your IdP. SCIM works alongside SAML single sign-on, or on its own.

**Before you begin:** you need administrator access to Talkspirit and an identity provider that supports SCIM 2.0, such as Okta or Microsoft Entra ID.

## What SCIM automates

Once configured, SCIM keeps Talkspirit in step with your company directory without an administrator doing it by hand:

- A new employee added to the directory gets a Talkspirit account automatically.
- An employee who leaves, or changes role, has their Talkspirit access suspended or removed the moment IT deactivates them centrally. This closes the gap where a departed employee still has access to company tools.

Talkspirit stores the configuration and exposes the endpoint. It does not run the sync itself: your identity provider's SCIM connector performs the moment-to-moment create, update, and deactivate calls. SCIM covers **user accounts only**; groups are not provisioned (see limitations below).

## How do I turn on SCIM provisioning?

1. Go to **Administration → Authentication**.
2. Open the **SCIM** tab.
3. Select **Generate token**.
4. Select the reveal icon, then copy the **Provisioning token**.

The provisioning token is the credential your IdP uses to authenticate its SCIM requests, so keep it secret. Share it only with the people configuring the identity provider's connector, over a trusted channel, and rotate it if you suspect it has leaked.

> **Warning:** Regenerating or disabling the token invalidates the current one immediately. Your IdP stops provisioning until you paste the new token into it, so update both sides together.

![Administration → Authentication → SCIM tab with a provisioning token generated and revealed, and the User matching, Welcome email, deprovisioning, and endpoint URL example rows](/images/administration-security/automated-user-provisioning-and-de-provisioning-scim-20/01-authentication-scim-provisioning-token.png)

## How do I configure my identity provider?

In your IdP's SCIM connector, enter:

- **SCIM URL (base URL):** `https://YOUR_DOMAIN/scim/v2`, where `YOUR_DOMAIN` is your Talkspirit host. The **Endpoint URL** example on the SCIM tab shows the full address.
- **Bearer token:** the provisioning token you generated.

Under **User matching**, Talkspirit links each provisioned account to an existing member by **Email address** or **External ID**, as shown on the SCIM tab. Prefer **External ID** if your identity provider can send a stable identifier that does not change when someone's email changes; otherwise use **Email address**. A mismatch between what your IdP sends and what Talkspirit matches on is the most common cause of duplicated or wrongly-linked accounts.

Then map your IdP's attributes to the fields Talkspirit reads:

- `userName` (the matching value; a valid email address when matching by email)
- `emails` (mark one entry as primary)
- `name.givenName` and `name.familyName`
- `displayName`
- `title` (the member's job title)
- `locale` (language) and `timezone`
- `phoneNumbers` (type `work` or `mobile`)
- `addresses` (type `work`, stored as the member's location)
- `userType` (`Member` or `Guest`)
- `externalId`

Any attribute Talkspirit does not read is ignored.

## How do I change a member's email address?

An email change has to reach Talkspirit as a full update, a SCIM `PUT`. Talkspirit's `PATCH` carries no `emails` attribute at all, so a `PATCH` that includes one succeeds and leaves the address in place. Check what your identity provider's connector sends for an email change: several send a `PATCH` for every update.

In the `PUT` body, when **User matching** is **Email address**, `userName` and the primary email entry must both carry the new address. Talkspirit refuses the request otherwise, saying the primary email should match `userName`. The rule does not apply when you match on **External ID**.

What happens next depends on where the person's account exists:

- **In your organisation only.** The address changes immediately, and they sign in with the new one.
- **In more than one organisation, under the same account.** The change is not applied yet. Talkspirit records it as a proposal, the member keeps the address they have, and they are asked to confirm the new one the next time they sign in. Accepting moves the address in every one of their organisations at once, and they sign in again with it. Declining changes nothing: no email is sent, nothing expires, and the next sync from your identity provider proposes the same address again.

Either way the SCIM request itself succeeds, so a success in your connector's log does not mean the address has already changed.

## How does de-provisioning work?

Choose the behaviour under **When a user is deprovisioned** on the SCIM tab:

- **Suspend the account** (default): the member keeps their data but can no longer sign in. This is reversible: a Talkspirit admin, or a later re-sync from your IdP, can reactivate the account with everything intact.
- **Anonymize the account**: the member's personal data is permanently and irreversibly removed. Their contributions stay visible but are no longer tied to identifying information.

When your IdP sets a user's `active` attribute to `false` (the routine offboarding flow for most connectors), Talkspirit suspends or anonymises the account according to this setting.

> **Warning:** anonymisation has no undo. Choose **Suspend** if you may need to reactivate someone later; choose **Anonymize** only when a data-retention or "right to be forgotten" policy requires permanently erasing a departed member's personal data.

A SCIM `DELETE` request behaves differently from the setting above: it always **anonymises** the account, regardless of whether you chose Suspend or Anonymize. It does not physically remove the record, so contributions remain, unattributed. An organisation owner cannot be deactivated this way.

Use the **Welcome email** switch to decide whether a newly provisioned member receives the welcome email.

## What are the current limitations?

- **Groups are not provisioned.** Send only Users; group requests return an empty result. Circle and Role membership stays managed within Talkspirit.
- **A provisioned account needs a valid email.** When matching is by email, the `userName` your IdP sends must be a valid email address, or the request is rejected. Map your IdP's email attribute, such as `userPrincipalName`, to `userName`.

## Troubleshooting

| Symptom | First things to check |
| --- | --- |
| A new employee was not created in Talkspirit | Confirm the IdP's SCIM connector is running and points at the current provisioning token. A token rotated in Talkspirit must also be updated on the IdP side. |
| A departed employee still has an active account | Check that the IdP-side deactivation actually fired (outside Talkspirit's visibility), then confirm the deactivation behaviour (Suspend vs Anonymize) matches what you expected. |
| Accounts are wrongly linked or duplicated | Check the **User matching** choice (Email vs External ID). A mismatch between what the IdP sends and what Talkspirit matches on is the usual cause. |
| An email address changed in your IdP but not in Talkspirit | Check that the connector sends the change as a full update (`PUT`): a `PATCH` carrying an email address succeeds and is ignored. If it does send `PUT`, the person may hold the same account in more than one organisation, in which case the change waits for them to confirm it at their next sign-in. |
| You need to rotate the token after a suspected leak | Generate a new token in Talkspirit, then immediately update the same value in the IdP's connector. Provisioning fails until both sides match. |
| The SCIM tab is not visible | Administration pages require the organisation-administrator role. Ask an existing admin to grant it. |

## Next steps

- [Configuring SAML Authentication](/en/administration-security/saml-authentication)
- [Setting up Okta SSO in Talkspirit](/en/administration-security/set-up-okta-sso)
- [Ways to add new members to your organisation](/en/administration-security/how-do-i-add-new-members-to-my-organization)
- [Editing, suspending, restoring or removing a member](/en/administration-security/how-to-edit-suspend-restore-or-delete-a-member-from-my-organization)