SCIM directory sync
Mirror joiners and leavers from your identity provider into a Dashies workspace, and know which parts of SCIM are deliberately not implemented.
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, and SAML SSO is connected. The SCIM card does not appear until SSO is configured, and generating credentials refuses until the domain is verified:
configure SAML SSO first - directory sync needs an existing tenant
verify your domain before configuring SCIMGenerate 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 |
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.
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
- Your identity provider reports the connection as healthy. Most IdPs have a "test connection" button on the provisioning tab. Use it before assigning anybody.
- 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.
- The audit log recorded it. The 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.
- 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.
- 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.