My single sign-on login fails

Check the domain, the certificate and the assertion first, and remember that the Owners of the account always have a password route back in.

Admins of a workspace with single sign-on, and the Owners of the account that holds it.

First: get back in. The Owners of the account that holds the workspace keep a password route as break-glass, precisely so a broken identity provider cannot lock the workspace out. Sign in that way, then diagnose.

Is the domain verified? Enforcement will not turn on until it is, but a DNS record that was later removed breaks the mapping from an email address to your connection.

Has the certificate expired or rotated? This is the most common cause of a connection that worked for months and then stopped. Identity providers rotate signing certificates; transglot validates the signature on the assertion, so a rotated certificate fails every sign-in at once. Paste the new one and save.

Do the URLs match exactly? The entity id and the sign-in URL have to match your identity provider character for character. A trailing slash is a mismatch.

Is the person assigned to the app? An identity provider will happily authenticate someone and then decline to release an assertion for an app they are not assigned to.

Is their email the same on both sides? The assertion's email is what maps to a transglot account. If the directory has one address and transglot another, the sign-in succeeds at the identity provider and lands nowhere.

Use Test connection. It runs a real sign-in and reports what came back, which is faster than reading logs.