SSO and Single Sign-On Problems

If your team signs in through Google Workspace, Microsoft Entra ID, Okta, or another SAML provider, login failures usually originate on the identity-provider side or in the handshake between it and Loomstack — not in your password. This guide covers the errors end users hit most, plus the checks admins should run. (For password resets and 2FA lockouts on standard accounts, see Troubleshooting Login and Account Issues instead.)

”User Not Assigned to This Application”

This error comes from your identity provider, not Loomstack:

1. Your IdP admin needs to assign you (or your group) to the Loomstack application in the IdP dashboard
2. In Okta: Applications > Loomstack > Assignments > Assign to People/Groups
3. In Microsoft Entra: Enterprise applications > Loomstack > Users and groups > Add user/group
4. After assignment, wait a minute and retry — no action is needed in Loomstack itself

Redirect Loop Between Loomstack and Your IdP

If the login bounces endlessly between the two sites:

1. Clear cookies for both app.loomstack.app and your IdP’s domain
2. Try an incognito window — a stale session cookie from a previous SSO configuration is the usual cause
3. Check your system clock: SAML assertions are time-stamped, and a device clock skewed by more than 3 minutes makes valid assertions look expired. Enable automatic time sync in your OS settings
4. If the loop persists for everyone on the team, the admin should re-check the ACS URL and Entity ID in the IdP config against the values shown in Settings > Workspace > Authentication

”No Loomstack Account Matches This Identity”

SSO matches users by email. This error means the email your IdP sends doesn’t match any workspace member:

1. Confirm which email your IdP profile uses — it may be j.smith@corp.com while your Loomstack invite went to jane.smith@corp.com
2. An admin can fix a mismatch under Settings > Team: click the member, choose Change email, and set it to the IdP-provided address
3. If you were never invited, an admin must add you first — SSO with just-in-time provisioning disabled (the default) does not create accounts automatically
4. Admins can enable auto-provisioning under Settings > Workspace > Authentication > Provision new users on first sign-in

Signed In but Landing in the Wrong Workspace

If your email belongs to multiple Loomstack workspaces:

1. After SSO login, click your avatar > Switch workspace
2. Set a default under Settings > Account > Default workspace
3. Bookmark the workspace-specific URL (app.loomstack.app/w/your-team) rather than the generic login page

Admin Checklist: Certificate and Metadata Errors

Errors like “Invalid signature” or “Unable to validate SAML response” indicate configuration drift:

1. In your IdP, check the certificate expiry date — expired signing certificates are the top cause of sudden, team-wide SSO outages
2. Download the fresh metadata XML from the IdP and re-upload it in Settings > Workspace > Authentication > Update metadata
3. Confirm the NameID format is set to email address in the IdP
4. Use Test connection on the same settings page before rolling out; it validates the full handshake without ending your current session
5. Keep at least one owner account with password fallback enabled so an SSO outage never locks the whole workspace out

Summary

Assignment errors and redirect loops are fixed on the identity-provider side; account-matching errors are fixed by aligning emails in Loomstack’s Team settings. Admins should watch certificate expiry dates, re-test after metadata changes, and keep a password-fallback owner account. If the Test connection tool passes but users still can’t sign in, contact support with the SAML trace from your browser’s network tab.