SSO login works for some users but fails for others

Short Description After enabling SSO in Hive9, a subset of users can't log in. The cause is almost always an email-format mismatch between Hive9 and your identity provider (IdP).

What this article answers

Why SSO can authenticate some users but reject others.
How to identify and correct the mismatch.
A workaround so blocked users can keep working while IT fixes the IdP.

What's happening

You've turned on SSO for your Hive9 instance. Most users log in successfully via the SSO redirect, but a handful hit an authentication error and can't get into the application.

Why this happens

Hive9 authenticates SSO users by exact email match between the email stored on the user's Hive9 record and the email returned by your identity provider (IdP).

The most common mismatch is case or alias format. For example:

Hive9 record: jane.doe@example.com
IdP claim: Jane.Doe@example.com

Some IdPs return emails in the format users typed when their corporate account was created (Jane.Doe@), while Hive9 records were imported or created with a lowercase version (jane.doe@). The two systems treat these as different identities.

Aliases cause the same problem — if a user's IdP sends j.doe@example.com but Hive9 has jane.doe@example.com, authentication fails even though both addresses route to the same mailbox.

How to fix it

Step 1 — Confirm the mismatch

Ask one of the blocked users for the exact email format their IT team has registered in your IdP (Okta, Azure AD, Ping, etc.).
Compare against Settings → Users in Hive9 — find the user's record and read the email field.
If the formats differ in any way (case, dots, aliases), that's the cause.

[SCREENSHOT NEEDED — Users grid with email field highlighted]

Step 2 — Align the IdP to Hive9 (preferred)

Your IT or IdP admin can update the IdP claim to return the email in the same format that's stored in Hive9. This is the cleanest fix because it doesn't require changes inside Hive9.

Step 3 — Or update the Hive9 record to match the IdP

Alternatively, an admin can update the email on each affected Hive9 user record so it matches the IdP claim. Note that:

The email change is recorded in Audit Logs.
The user's owned objects, approval history, and notification settings all carry over — only the login identity changes.

[SCREENSHOT NEEDED — Edit user profile with email field active]

Step 4 — Workaround while IT investigates

Affected users can log in directly using the standard plan.hive9.com URL with their password instead of the SSO redirect, as long as their password is set. If they don't have a password, they can trigger Forgot Password to set one.

This is a temporary workaround. Aligning the IdP and Hive9 emails is the proper long-term fix.

Common questions

Are emails case-sensitive in Hive9? For SSO matching, yes — the authentication compares the strings literally. The Hive9 UI is otherwise tolerant of case, but the SSO claim must match exactly.

My IdP supports multiple email formats. Which should I use? Whichever you used when the Hive9 user records were originally created. If you're not sure, audit a sample of records in Settings → Users to see the dominant format and standardize the IdP to that.

Will SSO start working immediately after I fix the mismatch? Usually yes, but some IdPs cache claims for a few minutes. Ask affected users to clear browser cache or try an incognito window if the fix doesn't take effect right away.