SSO troubleshooting

Common SAML sign-in and setup problems, what causes them, and how to fix them. If you’re stuck after these, contact support with the error code you saw.

Where errors show up

The sign-in page reports a short error code when a SAML sign-in fails. Deeper assertion failures (bad signature, malformed XML) are handled by the identity platform and never reach the app — those are visible to platform staff in the identity toolkit logs, linked from the Activity card in your SSO settings.

Sign-in problems

Symptom / error	Likely cause	Fix
“If you started from your company’s app dashboard, that path isn’t supported” — or clicking an IdP tile does nothing / lands you signed out	IdP-initiated sign-in. Starting from a tile/bookmark in Okta, Entra My Apps, or the Google apps launcher. We only support SP-initiated SSO — a platform constraint, not a setting.	Go to our sign-in page and enter your work email. Point any IdP app tile at /login instead of an IdP-initiated URL.
“Sign-in with your organization failed — contact your IT admin.”	The IdP returned an assertion we couldn’t accept — often a certificate mismatch, a NameID that isn’t an email, or the user isn’t assigned to the app.	Confirm the signing certificate on file matches the IdP’s current certificate, the NameID is the user’s email, and the user is assigned to the app in the IdP. Re-run Test Connection.
Password or Google sign-in is rejected: “This domain requires single sign-on.” (event code enforced_sso_blocked)	The connection has enforced SSO on for this domain, so password/Google are disabled for those users.	Sign in with SSO instead (enter your work email on the sign-in page). If you must use a password (e.g. a break-glass admin), an admin can add your account to the break-glass list or turn enforcement off.
auth/account-exists-with-different-credential when signing in with SSO	You already have an account created with a password or Google using the same email.	Sign in once with your existing method when prompted; we link your SSO identity to the existing account. After that, SSO sign-in works directly.
Entering a work email doesn’t route to SSO — it shows the password form	The email’s domain isn’t verified, or the connection isn’t active yet. For privacy, unrecognized domains fall through to the password form.	In SSO settings, confirm the domain shows verified and the connection status is active. Complete domain verification and Activate if not.
“This SSO connection is not set up yet” / not provisioned	The connection exists but isn’t active, or IdP config is incomplete.	Finish the IdP config (Entity ID, SSO URL, and certificate), verify a domain, then Activate. See your provider’s guide from the SSO overview.

Setup & configuration problems

Symptom / error	Likely cause	Fix
Test sign-in works but no user is created / wrong role	In test mode (a verified-but-inactive connection) we intentionally provision nothing. Roles come from your provisioning setting: JIT uses the default role; invite-only requires a matching pending invite.	Activate the connection for real provisioning. Check the Provisioning and Default role settings in the Connection Setup card.
NameID / attribute shows something other than an email in the test result	The IdP’s Name ID isn’t mapped to the user’s email.	Set the Name ID format to email and map it to the user’s email attribute (Okta EmailAddress, Entra user.mail, Google EMAIL / Primary email). Then re-test.
Sign-ins started failing after a while (previously worked)	The IdP’s signing certificate expired or was rotated. The Activity card warns 30 days before expiry.	Get the new certificate from your IdP and paste it into the Connection Setup card (paste replaces the certificate on file), then save.
Domain won’t verify — “TXT record not found yet”	The TXT record hasn’t propagated, is on the wrong host (a subdomain instead of the apex), or the value doesn’t match exactly.	Confirm the record is a TXT at the apex (host @) with the exact nofait-sso-verification=… value. Wait for propagation (up to 48h) and click Check now again. See the DNS guide.
“Verification was attempted too recently” (HTTP 429)	Domain checks are rate-limited to about one every 10 seconds.	Wait a few seconds and click Check now again.
“This domain is not available for SSO verification.”	The domain is already claimed by another connection (possibly elsewhere in your own org). A domain can belong to only one connection.	Contact support — we’ll help determine and reassign ownership.
Can’t turn on Enforce SSO	Guardrail: enforcement requires the connection to be active, have at least one verified domain, and that you have completed a SAML sign-in with it (so you can’t lock everyone out).	Activate the connection, verify a domain, then sign in once via SSO yourself. You become the break-glass account and can then enforce.
The SSO tab / settings disappeared	SSO requires the Enterprise tier. If the subscription lapsed off Enterprise, the connection is automatically disabled and the settings are hidden.	Restore the Enterprise subscription, or contact support to re-enable SSO.

Still stuck?

Contact support with your connection slug and the exact error code shown on the sign-in page. Platform staff can inspect the identity toolkit logs for deep assertion failures that don’t surface in the app.