Single Sign-On & SCIM Directory Sync
Available on eligible plans, this lets agents and admins sign in with your existing identity provider instead of a QueueDesk password, and optionally keeps your member directory in sync automatically.
1. Setting Up SSO (Settings → Identity)
Configure your identity provider (IdP) — Azure AD, Okta, Google SSO, or any standards-compliant provider:
- •Protocol — SAML or OIDC.
- •SAML needs: SSO URL, Issuer/Entity ID, X.509 certificate (and optionally your Azure tenant ID).
- •OIDC needs: Issuer URL, Tenant/Client ID.
Two behavior toggles:
- •Create accounts on first login (JIT) — new users are provisioned automatically the first time they sign in through your IdP, instead of needing a manual invite first.
- •Require SSO for all members — blocks email/password sign-in for everyone except the workspace owner, who always keeps an email/password break-glass path in case of IdP outages.
The page also shows the read-only values your IdP admin needs to complete the setup on their end: SP Entity ID, ACS / Reply URL, SCIM tenant URL, and the Relay state (your workspace slug).
2. Mapping Roles (SAML)
Under App role mapping, map IdP group/role claims to QueueDesk roles (Admin, Agent, Employee), plus a default role for anyone who doesn't match a specific mapping. This is what decides whether a newly-provisioned user lands in the agent queue or the employee portal.
3. SCIM Directory Sync
Generate a SCIM token from the same page to let your IdP push user creation, updates, and deactivation automatically (no more manually offboarding people in two places). Users provisioned via SCIM start as Employee by default.
Review synced profiles — job title, department, location, manager, group memberships, last synced time — under Settings → Identity directory. This view is read-only; it mirrors what your IdP has, it doesn't let you edit directory attributes directly in QueueDesk.
4. Turning It Off
Use Delete IdP configuration in the danger zone to fully remove SSO/SCIM setup. Existing accounts remain, but they'll need email/password (or a fresh invite) to sign in afterward.
Next, read Connecting Integrations & Custom MCP Servers — a related but separate feature that lets QueAssist take actions like resetting passwords, distinct from SSO login.