---
title: SCIM directory sync
description: Mirror joiners and leavers from your identity provider into a Dashies workspace, and know which parts of SCIM are deliberately not implemented.
updated: 2026-08-05
tier: enterprise
---

SCIM keeps workspace membership in step with your directory: when someone is
assigned the Dashies app in your IdP they get added, and when they are
deactivated or unassigned they get removed.

**Prerequisites, in this order:** the workspace is on Enterprise, its email
domain is [verified](/admin/domain-verification), and
[SAML SSO is connected](/admin/sso). The SCIM card does not appear until SSO is
configured, and generating credentials refuses until the domain is verified:

```bash
configure SAML SSO first - directory sync needs an existing tenant
verify your domain before configuring SCIM
```

## Generate the credentials

Open **Settings**, switch into the workspace, open its **Security** section, and
click **Generate SCIM credentials**.

You get two values, each with a **Copy** button:

| Value | Paste it into |
|---|---|
| **SCIM URL** | Your IdP's SCIM base URL / tenant URL field |
| **Bearer token** | Your IdP's SCIM bearer token / secret token field |

:::danger{title="The token is shown once and cannot be regenerated in the app"}
The app is explicit about this: "We don't store the token - if you lose it,
contact support to regenerate."

Copy both values into your identity provider **before you close or navigate away
from that screen**. There is no way to display them again, and there is no
rotation button. Trying to generate a second time returns:

> A SCIM directory is already registered for this workspace. Rotating the token
> is not supported yet - contact support if you need a new one.

Put the token in your password manager on the way past, not afterwards.
:::

## What syncs

Three events do something. Everything else is deliberately ignored.

| In your identity provider | In Dashies |
|---|---|
| A user is created or assigned the app | Added to the workspace as a **member**. An existing admin is never demoted. |
| A user is **deactivated** | Removed from the workspace. |
| A user is deleted or unassigned | Removed from the workspace. |

**Removal is the same narrow removal as doing it by hand.** The person keeps
their Dashies account and can still sign in; they simply lose the workspace, its
dashboards, its data sources, and every team inside it. Exactly what that does
and does not revoke is in [Members and roles](/admin/members#remove-someone).

Every email your directory sends must end with the workspace's verified domain.
Events for any other address are rejected.

## What is not supported

Be explicit with whoever runs your IdP about these, because a directory
configured to expect them will look broken.

- **Group sync does nothing.** Group events are answered with "unhandled event",
  which stops your IdP retrying them. Groups are not mirrored to workspaces, and
  group membership does not map to anything in Dashies.
- **Roles cannot be provisioned.** Everyone SCIM adds is a **member**. There is
  no attribute or group that grants admin. Promote admins by hand in the
  **Members** section.
- **Profile updates are not applied.** Changing a name or an email address in
  your directory sends an update that Dashies accepts and ignores. Only
  deactivation is acted on.
- **Reactivating is not the reverse of deactivating.** Deactivating removes the
  membership; setting the user active again is one of the ignored updates. To
  bring someone back, unassign and reassign the application, or invite them by
  hand.

## Check it worked

1. **Your identity provider reports the connection as healthy.** Most IdPs have a
   "test connection" button on the provisioning tab. Use it before assigning
   anybody.
2. **Assign one real person and watch them appear.** Assign the Dashies
   application to a single test user in your IdP, then open the workspace's
   **Members** section. They should appear as a member. Directory pushes are not
   instant, so give your IdP its sync interval before concluding it failed.
3. **The audit log recorded it.** The [audit log](/admin/audit-log) in the same
   section should show a line reading "was provisioned by SCIM". This is the
   check that distinguishes "SCIM added them" from "they signed in through SSO
   and auto-joined", which produce the same member row.
4. **Deactivate the same test user and watch them leave.** Deactivate them in the
   IdP; they should disappear from the member list, and the audit log should show
   "was deprovisioned by SCIM". Testing only the joiner half is the common
   mistake, and the leaver half is the one that matters for offboarding.
5. **Confirm their account survived.** The test user should still be able to sign
   in to Dashies and see their own personal dashboards. If they cannot sign in at
   all, something other than SCIM is wrong.