> For the complete documentation index, see [llms.txt](https://docs.euno.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.euno.ai/setup-configuration/scim-provisioning.md).

# SCIM Provisioning

## 🔐 SCIM Provisioning

SCIM (System for Cross-domain Identity Management) lets your Identity Provider (IdP) create, update, and deactivate Euno users and groups automatically. Once configured, your IT admin manages access to Euno from the IdP — Okta, Microsoft Entra ID, or any other SCIM 2.0–compliant IdP — without having to invite users individually from Euno.

> Compatible with **Okta** and **Microsoft Entra ID** (Azure AD).

### What SCIM Provisioning Does

When SCIM is enabled and your IdP is connected:

* **User lifecycle is mirrored**: when a user is added, renamed, deactivated, or removed in your IdP, the same change is applied in Euno on the next provisioning cycle.
* **Group memberships drive personas**: you map IdP groups to Euno personas. Anyone in a mapped group automatically gets that persona; remove them from the group and the persona is revoked.
* **Manual personas still work**: existing manually-assigned personas are preserved alongside SCIM-derived ones. SCIM-derived personas are visibly locked in the persona picker so admins know they're managed by the IdP.

<figure><img src="/files/2V53sLD1xY9waPAm7Qhw" alt=""><figcaption></figcaption></figure>

### Prerequisites

SCIM requires **Single Sign-On (SSO) to be configured first** for your account. SCIM is governed by the same SSO configuration — when SSO is removed, SCIM is treated as torn down: SCIM-derived personas disappear and provisioning halts on the next cycle.

If SSO is not yet configured, see [SSO login](/setup-configuration/linked-accounts/sso-login.md) before continuing.

### Stage 1: Enable SCIM in Euno

#### Step 1: Open SCIM Provisioning Settings

1. Navigate to **User Menu → Account Settings → SCIM Provisioning**
2. If SSO is not yet configured for your account, you'll see a warning and the **Enable SCIM** toggle will be disabled

<figure><img src="/files/AtwGwxAJ9jhOMfOOHBlz" alt=""><figcaption></figcaption></figure>

#### Step 2: Enable SCIM

Click the **Enable SCIM provisioning** toggle. The change is saved immediately. A green **SCIM enabled** indicator appears, and the rest of the configuration form expands.

#### Step 3: Generate a Bearer Token

The bearer token is the credential your IdP uses to authenticate with Euno. Generate it now so you can paste it into your IdP in Stage 2.

1. Click **Generate token**
2. The token is shown **once** in a modal — copy it immediately. You will not be able to see it again.
3. Store the token somewhere secure until you've finished IdP setup.

<figure><img src="/files/7ELbXdMyskdx8SIGLeU9" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/RrixlPjd2u9rNHFwfTWJ" alt=""><figcaption></figcaption></figure>

You can rotate the token at any time. Rotating immediately invalidates the existing token — any IdP currently using the old token will start receiving 401s until you paste the new one. Click **Rotate token** to replace it; **Disable token** to revoke it entirely.

#### Step 4: Copy the SCIM Base URL

Click **Copy** next to the **SCIM base URL**. You'll paste it into your IdP in Stage 2.

#### Step 5: Configure Optional Settings

Two additional fields control SCIM behavior:

| Field                     | Description                                                                                                                                                                      |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Default persona**       | The persona assigned to SCIM-provisioned users who are not in any mapped group. Leave unset to deny access to such users; set it to grant a baseline persona (typically Viewer). |
| **Account Admin mapping** | A safety knob. While set to **Disabled**, no group can be mapped to the Account Admin persona. To allow it, change to **Allow explicit mapped group only**.                      |

### Stage 2: Configure Your Identity Provider

> **⚠️ Important**: The SCIM `userName` attribute must match the user's primary email — the exact identifier they use to sign in via SSO.
>
> Both Okta and Microsoft Entra ID default to email-shaped values for `userName` (Okta's user login and Entra's `userPrincipalName`), which works for standard setups. **Verify the mapping on your IdP before going live.**

#### Stage 2A: Microsoft Entra ID (Azure AD)

1. In the Microsoft Entra admin center, go to **Enterprise applications → New application**
2. Choose a **non-gallery / custom SCIM application** (or your existing SCIM app)
3. Open the **Provisioning** blade → **Get started** → set Mode to **Automatic**
4. Under **Admin Credentials**, paste:
   * **Tenant URL**: the SCIM base URL from Stage 1, Step 4
   * **Secret token**: the bearer token from Stage 1, Step 3
5. Click **Test Connection** — you should see a green success message
6. Save
7. Under **Settings**, set Scope to **Sync only assigned users and groups**
8. Assign users and groups to the application (Users and groups blade)
9. Click **Start provisioning**

The initial provisioning cycle can take up to 40 minutes. Subsequent incremental cycles run every \~40 minutes. To push a specific change immediately, use **Provision on demand** from the Provisioning blade.

<figure><img src="/files/YiKcVWNvdmdIkdkGHVNp" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/t6n4hvzQMyXQkEu1Kbcf" alt=""><figcaption></figcaption></figure>

#### Stage 2B: Okta

1. In the Okta admin console, go to **Applications**
2. Open the app you want to enable SCIM provisioning on
3. Open the **Provisioning** tab → **integration**
4. Set **SCIM connector base URL** to the SCIM base URL from Stage 1, Step 4
5. Set **Unique identifier field for users** to `userName`
6. Under **Supported provisioning actions**, check **Push New Users**, **Push Profile Updates**, and **Push Groups**. Leave the Import options unchecked.
7. Set **Authentication Mode** to **HTTP Header**
8. Under **HTTP Header → Authorization**, paste the bearer token from Stage 1, Step 3 (the **Bearer** prefix is added automatically)
9. Click **Test Connector Configuration** — you should see a green success message
10. Save
11. On the **Provisioning → To App** settings page, enable **Create Users**, **Update User Attributes**, and **Deactivate Users**
12. Assign users to the application (Assignments tab) and push groups (Push Groups tab)

<figure><img src="/files/5rzlk0nxR0brhrozuzsJ" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/JQ4d6K1ug1ECCKK0eHjw" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/2JJLYxAa60LGF0P22FhE" alt=""><figcaption></figcaption></figure>

### Stage 3: Map IdP Groups to Personas

After your IdP has pushed groups to Euno, you can map each group to a Euno persona.

#### Step 1: Open the Mappings Section

In **SCIM Provisioning**, scroll to **Group to persona mappings**. Pushed groups appear in the dropdown.

#### Step 2: Add a Mapping

1. Click **Add mapping**
2. Select an IdP group from the dropdown
3. Select a persona to grant to its members
4. Click **Save**

The mapping is applied within \~10 seconds across all open sessions.

<figure><img src="/files/aKhiKfJ5Yenm5Fajhy9f" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/N6rIbLcLNkSJen7Zo1oR" alt=""><figcaption></figcaption></figure>

#### Multiple Group Memberships

If a user is a member of multiple mapped groups, they receive **all** the mapped personas — switchable from the User Menu like any other multi-persona user. See [Personas](/setup-configuration/personas.md) for how persona switching works.

#### Default Persona Fallback

When a SCIM-provisioned user is in **no mapped group** and you've set a **Default persona** in Stage 1 Step 5, that persona is granted automatically. If no default is set, the user has no access until they're added to a mapped group or assigned a manual persona.

### Account Admin Mapping (Safety Knob)

Granting the Account Admin persona via a group mapping is an exceptional operation — it gives anyone in that group full administrative control. To prevent accidental escalation, the **Account Admin mapping** setting is **Disabled** by default.

To grant Account Admin via SCIM:

1. Change **Account Admin mapping** to **Allow explicit mapped group only**
2. The Account Admin persona now appears as an option in the Mapping dialog and in the Default persona dropdown
3. Add a mapping for the appropriate IdP group → Account Admin

If you later want to remove the Account Admin mapping option entirely, you must first remove any existing mapping that references it. Euno will block the flip with an error otherwise.

### Coexistence: Manual + SCIM-Derived Personas

A user can have both **manually-assigned personas** (via the Stakeholders page) and **SCIM-derived personas** (via group mapping or default persona) at the same time.

In the Stakeholders persona picker:

* **SCIM-derived persona chips are locked** with a "Managed by SCIM" subtitle and a lock icon. They cannot be toggled — only the IdP can change them.
* **Manually-assigned persona chips are editable** — admins can still add or remove them via the picker.
* The **Remove from account** action is hidden for SCIM-managed users. To deprovision, remove the user from your IdP.

<figure><img src="/files/2OU8rbkBHIUOMQU01o4m" alt=""><figcaption></figcaption></figure>

### What Triggers a Sync

| Event in your IdP                            | What happens in Euno                                                                                    |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| User added or assigned to the app            | New SCIM user created; SCIM-derived personas applied based on group memberships                         |
| User profile updated (name change)           | User's display name updated in Euno                                                                     |
| User deactivated or unassigned               | User's SCIM-derived personas removed; user remains visible only if they have manually-assigned personas |
| User permanently deleted from IdP            | User's SCIM record removed; any manually-assigned personas are preserved                                |
| User added to or removed from a mapped group | SCIM-derived personas adjusted; change applies within \~10 seconds                                      |
| New group pushed                             | Group becomes available in the Mappings dropdown                                                        |
| Group renamed                                | Mapping persists, name updates in the Mappings table                                                    |
| Group deleted                                | Any mapping referencing it is removed; affected users lose those personas                               |

### Audit Log

Every SCIM operation — both IdP-pushed and admin-driven changes — is recorded in the **Events** section of the SCIM Provisioning page. Events include the operation type, the affected user or group, the actor (the IdP for pushes; the admin email for config changes), and a timestamp.

<figure><img src="/files/9IFbjhMVlIxB0L9bSy42" alt=""><figcaption></figcaption></figure>

The events page is paginated and ordered most-recent-first. Use it for forensic review or to verify that recent IdP changes have propagated correctly.

### Troubleshooting

#### A user can sign in via SSO but has no personas

The most common cause is a `userName` mismatch between SCIM and SSO. Verify in your IdP that the SCIM `userName` attribute maps to the same email the user signs in with. Both Okta and Entra default to this; the mismatch usually appears when an admin has explicitly customized the mapping (e.g. mapping `userName` to `samAccountName` or `employeeId` instead of email).

#### Provisioning is failing with 401 errors

The bearer token may have been rotated or disabled. Re-generate the token in Stage 1 Step 3 and paste the new value into your IdP.

If SSO has been removed from your Euno account, SCIM is also considered torn down — all incoming provisioning requests will fail with 401 until SSO is restored.

#### A group mapping was added but users don't see the persona

Group-to-persona mappings apply within \~10 seconds across all open sessions. If the persona still doesn't appear after that, verify:

1. The user is actually a member of the mapped group on the IdP side
2. The user has been provisioned (visible in the Stakeholders list with a **Managed by SCIM** badge)
3. The user's SCIM record is `active` (not deactivated)

#### I want to test what my IdP is sending

The Events page captures every SCIM operation with the full (redacted) request payload. Filter by recent operations and inspect the payload to confirm what your IdP is actually pushing.

### Removing SCIM

To turn off SCIM provisioning for your account:

1. In your IdP, **stop provisioning** to disconnect the integration
2. In Euno SCIM Provisioning, click **Disable token** to revoke the bearer token
3. Disable the **Enable SCIM** toggle if you want to fully turn off SCIM features

Existing SCIM-provisioned users retain their manually-assigned personas (if any). To fully remove a user, remove them from the IdP — Euno will deprovision them on the next sync — or use the User Management Remove flow once SCIM is fully turned off.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.euno.ai/setup-configuration/scim-provisioning.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
