SCIM Provisioning
Let your identity provider add, update and remove Qualflare workspace members over SCIM 2.0, with a one-time token and your SSO role rules.
Reviewed by Qualflare Team on
Last updated
To let your identity provider add, update and remove Qualflare workspace members, turn on SCIM 2.0 provisioning under SCIM Provisioning; you need the Owner role, the Enterprise plan and a working SSO connection.
Before you begin
Owner · workspace (requires the Owner role in the workspace) Enterprise (available on Enterprise)You also need a working SSO connection and verified domains.
SCIM lets your identity provider automatically create, update, and remove Qualflare workspace members to match your directory — supported by Okta and Microsoft Entra ID.
Provisioning removes members, not just adds them. When your identity provider unassigns someone, SCIM deletes their workspace membership and signs them out everywhere immediately. Their underlying Qualflare account is not deleted — only their membership in this workspace. Renaming a group at the identity provider is also live: every member's role is recomputed against your role rules at that moment, using the group's new name.
Set up provisioning
Open SCIM Provisioning in the workspace sidebar, under Administration.
Generate a token
Click Generate token. The plaintext token is shown exactly once — copy it immediately, it cannot be retrieved again later (only a masked prefix is shown afterward).
Connect your identity provider
Paste the SCIM base URL and the token into your identity provider (Okta: "Base URL" / "API Token"; Entra: "Tenant URL" / "Secret Token").
Turn on provisioning
Turn on Provisioning enabled. This is a separate step from generating the token on purpose — minting a credential and arming an endpoint that can remove members are different decisions.
Regenerate or revoke the token
Regenerate token (confirm with Regenerate token) replaces the token immediately (paste the new one into your identity provider or provisioning breaks). Revoke (confirm with Revoke token) clears the token and turns provisioning off in the same action — nothing already provisioned is undone, but no further changes apply.
How provisioning behaves
- A user can only be provisioned into a verified domain — this is what stops a directory from silently granting access to an outside address. If your identity provider's directory includes people outside your verified domains, they'll fail to provision.
- The last remaining workspace Owner cannot be deprovisioned or removed by SCIM.
- Groups pushed over SCIM are matched against the same role rules configured under SSO attribute mapping.
Troubleshoot
| Symptom | Likely cause |
|---|---|
| 401 on every request | Token is wrong, was regenerated after being pasted into the identity provider, or the SSO connection was removed, which deletes the token |
| "not configured" error | The workspace isn't on a plan that includes SSO, or Qualflare support disabled the connection |
| "not enabled" error | The Provisioning enabled switch or the SSO Connection enabled switch is off |
| "unavailable while this workspace is suspended or deactivated" error | The workspace is suspended or deactivated. Provisioning works again once it's reinstated |
| A specific user fails to provision | Their email domain isn't a verified domain on this workspace |
| A user can't be removed | They're the workspace's last Owner. SCIM never removes the last Owner |
Next steps
- Role rules: which role a provisioned member gets.
- Audit Logs: SCIM changes show with the SCIM actor.
- Verified Domains: add the domains your directory uses.
Verified Domains
Prove that your company owns an email domain with a DNS TXT record, so Qualflare sends members at that domain to your SSO identity provider.
Audit Logs
See who did what, when and in which project in a Qualflare workspace audit log, with its columns, actor types, filters and who can view it.