Microsoft single sign-on problems
Every Microsoft sign-in error in one place: not configured, something went wrong, an expired setup link, a domain mismatch, no account found, the button not showing, a terminated employee blocked, and people on a different domain.
Microsoft single sign-on (SSO) can fail at several points, and the on-screen message does not always tell you which one. This article gathers every Microsoft sign-in problem in one place: find the symptom that matches what employees are seeing, then follow the fix for it. Most issues are settled either in your company's Microsoft (Entra ID) app registration or in the employee's record in the HR area, not by retrying the same sign-in.
Microsoft sign-in is not configured for your company
If an employee tries to sign in with Microsoft and sees Microsoft sign-in is not configured for your company. Please contact your IT administrator., CLVR could not find a complete, active Microsoft sign-in setup that matches their email domain.
CLVR shows this error when it cannot match the employee's email domain to a finished configuration. For a configuration to count as ready, all of the following have to be true:
- Microsoft sign-in is turned on for the company.
- The saved setup has a client ID, a tenant ID, a client secret, and a domain.
- That saved domain exactly matches the part of the employee's email after the
@.
If any one of those is missing or does not match, CLVR treats the company as not configured for that domain and falls back to the error. There are three common causes:
- Setup was never finished. Your IT contact received the setup link but did not complete the form, so no configuration was saved.
- The saved details are incomplete. Setup was started but one of the values (client ID, tenant ID, client secret, or domain) was left out, so the configuration is not usable.
- The domain does not match. The domain entered during setup is different from the domain in the affected employees' email addresses, for example a setup saved for
company.comwhile staff sign in with@company.se.
A wrong or mismatched domain looks the same to employees as no setup at all: both produce the "not configured" message. So a clean-looking setup can still trigger this error if the domain does not match the addresses people actually sign in with.
To fix it:
Confirm setup was finished. Check with your CLVR contact (or the IT colleague who handled it) that the Microsoft sign-in setup form was completed and saved, not just opened.
Check the domain on file. Compare the domain saved during setup with the real email domain your affected employees use to sign in. They have to match exactly.
Redo setup if any value is missing. The client ID, tenant ID, client secret, and domain are saved together, so a partial setup cannot be patched field by field. Ask your CLVR contact for a fresh setup link and have your IT team re-enter all four values in one pass.
Confirm it is live. Once the configuration is saved with the correct domain, have one employee on that domain test the Microsoft sign-in.
No one is locked out while this is being fixed. Employees on the affected domain can still sign in with a sign-in link emailed to them (with a one-time code in the same email), or with email and password if your company is set up for password sign-in. The sign-in page detects the right fallback automatically once they enter their work email.
Something went wrong with Microsoft sign-in
When an employee tries to sign in with Microsoft and the sign-in cannot complete, CLVR Benefits shows Something went wrong with Microsoft sign-in. Please try again. This is a deliberately generic message: a few different problems all surface the same way, and almost all of them are fixed in your company's Microsoft (Entra ID) app registration rather than in CLVR.
The message appears whenever the Microsoft step of sign-in fails to finish. That can happen at three points: Microsoft refuses the request before it reaches CLVR (for example a redirect mismatch or a missing permission); CLVR receives the sign-in but cannot exchange it with Microsoft for an access token (for example because the client secret is wrong or has expired); or the token works, but CLVR cannot read the employee's profile from Microsoft (the User.Read call fails). All three land on the same screen, so the message alone does not tell you which one it was.
The vast majority of cases come down to one of these three causes:
- The redirect URI does not match. The redirect URI registered in Azure must match the one CLVR uses exactly, character for character. A typo, a missing path, or an extra trailing slash is enough to make Microsoft reject the request.
- Consent for User.Read is missing. CLVR reads the signed-in employee's email and name through Microsoft Graph using the User.Read permission. If that permission is not added, or consent for it was never granted for your organization, sign-in cannot complete.
- The client secret has expired or is wrong. Azure client secrets expire on a date set when they are created. Once a secret expires (or if the wrong value was entered during setup), CLVR can no longer exchange the sign-in with Microsoft.
Ask your IT team to confirm the following in the company's Microsoft Entra app registration:
Redirect URI. Under Authentication, confirm the exact redirect URI CLVR provided is registered as a Web platform redirect, with no typos or extra characters.
Microsoft Graph permission. Under API permissions, confirm Microsoft Graph → User.Read (Delegated) is present, and that Grant admin consent has been done for your organization. Without consent on this permission, sign-in cannot complete.
Client secret. Under Certificates & secrets, confirm a client secret exists and has not passed its expiry date. Remember that only the secret Value works, never the Secret ID.
If all three look correct and sign-in still fails, have your IT team attempt a sign-in and note the exact wording Microsoft shows before the CLVR screen, since CLVR forwards that text and it usually points straight at the cause.
A client secret is the one part of the setup that expires on its own, so it is the most common reason a previously working Microsoft sign-in suddenly stops. When that happens, your IT team creates a new client secret in Certificates & secrets and copies the new Value, then re-enters it into CLVR through the same secure setup page they used originally. Because that page is reached through a one-time link, your CLVR contact sends a fresh setup link so the new secret can be submitted. You do not re-enter the secret yourself from inside CLVR Benefits, and the secret value is never shown back to you once saved.
If the screen says sign-in is not configured rather than that something went wrong, the setup was never completed or saved, not that an existing setup broke. See the "not configured" section above instead of debugging Azure.
Email domain mismatch during sign-in
When your company uses Microsoft single sign-on, CLVR checks that the email Microsoft returns is on the exact domain set up for your company. If someone completes Microsoft sign-in with an account on a different domain, the attempt is rejected before any session is created, and they land back on Sign in with the same generic Something went wrong with Microsoft sign-in. Please try again. message.
The comparison is case-insensitive, so capitalisation differences (Company.com versus company.com) are never the cause. The block is about the domain itself, not how it was typed. The most common reason is that someone reached the Microsoft step with a work account on a second domain or a personal Microsoft account, rather than the account on your configured company domain, for example:
- A secondary or legacy email domain that your company also owns but that is not the one configured for SSO.
- A personal Microsoft account that happened to be signed in to the browser.
- A guest account in a different Microsoft tenant.
This is intentional. The check is what stops accounts from outside your configured domain from getting a CLVR session through your company's single sign-on. The affected person should sign in with the right account on your configured company domain (signing out of Microsoft in the browser first avoids the wrong account being picked up automatically), or fall back to a sign-in link, the one-time code from the same email, or email and password where that is enabled.
A domain mismatch does not get its own on-screen wording, so if you are helping someone troubleshoot, the domain of the account they used is the thing to check first.
No account found for this email address
When an employee signs in with Microsoft, CLVR takes the email address Microsoft returns and looks for a matching employee in your company. If no employee record uses that exact email, sign-in stops with No account found for this email address, even though the Microsoft password and the domain check both passed.
A successful Microsoft sign-in proves who the person is to Microsoft, but it does not create a CLVR Benefits account on its own. No account found for this email address means CLVR has no employee using that email yet. The employee sees the message along with a Try again button, but trying again will not help on its own, because the underlying record needs to be corrected first. There are two common reasons the match fails:
- The employee has not been added to CLVR Benefits yet. Microsoft can sign anyone in your tenant in, but only people your HR team has added to CLVR have an account here.
- The email in CLVR differs from the Microsoft work email. CLVR uses the address Microsoft sends back from the work account. If the employee was added under a different address (for example an old or alternative spelling), the two will not line up.
The fix is to make sure an active employee exists in CLVR Benefits with the exact email address Microsoft returns. HR users can do this from the Employees area:
Open Employees (under Add / Manage Employees) and search for the person by name.
If they are not listed at all, add them with Add Employee. Use Add Single Employee for one person, or Bulk Import for several. Set the Email field to their Microsoft work email.
If they are listed but with a different address, open their record and correct the Email field so it matches their Microsoft work email exactly.
Once the record exists with the right email, ask the employee to return to the sign-in page and select Continue with Microsoft again.
When you change an employee's email in CLVR Benefits, their sign-in identity updates with it automatically. You do not need to update a separate login address. Watch for subtle differences such as an extra dot, a missing letter, or a different alias on the same domain: CLVR matches the full address, so any difference counts as a different email.
The Continue with Microsoft button does not appear
If the Continue with Microsoft button does not appear for your domain, the sign-in page did not find an active Microsoft sign-in setup for that email. The page checks the email domain as you type and again when you continue, and shows Continue with Microsoft only when all of these are true for that domain:
- The Microsoft sign-in setup was completed and saved.
- All required values are present: the domain, client ID, tenant ID, and client secret.
- The configured domain matches the email domain exactly.
When any of these is missing, the page falls back to the next available method, which is usually a sign-in link (and a password option for companies set up that way). Run these checks:
Confirm setup actually finished. Ask your IT team whether they reached the Setup complete confirmation on the setup page after selecting Save and enable. If they closed the page before that confirmation, the credentials were never saved, so nothing is active yet.
Check the domain matches exactly. The domain entered during setup has to match what employees type after the @, character for character. If employees use company.com but a regional variant like company.se was saved, the page will not show Microsoft for company.com addresses. Capitalisation does not matter, but the rest of the domain must be identical.
Enter a full work email. The domain check only runs once there is a complete address with a domain after the @. A half-typed email, or just a name with no @company.com, will not trigger the Microsoft option.
Test on the configured domain. Use a real employee email on the exact domain that was set up. A colleague on a different domain will keep seeing their own sign-in method, which is expected, not a fault.
When everything is right, the page swaps the Send sign-in link button for a notice titled Microsoft sign-in ("Your company uses Microsoft sign-in. Click the button below to sign in with your work account.") and a single Continue with Microsoft button. That swap is the signal SSO is live for the domain.
A terminated employee cannot sign in
A successful Microsoft sign-in proves who someone is to Microsoft, but it does not decide whether they still have access to CLVR Benefits. After Microsoft confirms the identity, CLVR matches the returned work email to an employee in your company and checks whether that person is still active. If the matched employee has been offboarded, CLVR stops the session at this final step, and the sign-in page shows a notice titled Account terminated:
Your account has been terminated. You no longer have access to CLVR Benefits.
Unlike most sign-in errors, this one does not offer a Try again button, because retrying with the same Microsoft account will reach the same result. The block is on the CLVR side, not on Microsoft's: Microsoft can still sign the person in, CLVR still finds their employee record because the email matches, but CLVR then sees the record marked as offboarded and refuses to create a session. Offboarding someone in your CLVR people list is enough to cut off their access; you do not need to disable their Microsoft account to achieve that.
An employee is offboarded when your HR team sets a Termination date for them in the Terminate employee panel on the employee's record (under Add / Manage Employees). A date in the past marks the person as terminated immediately; a date in the future keeps access until that date, then removes it automatically. If someone who still works for you sees Account terminated, the most likely cause is that their record was offboarded by mistake, for example a backdated termination date or an accidental entry:
Open Employees (under Add / Manage Employees) and find the person by name.
Open their record and look at the termination panel. If it shows they were terminated on a date, that is why they are blocked.
Confirm whether the termination is genuinely intended. If it is not, contact your CLVR contact so the offboarding can be corrected for that person.
Once the record is active again, the employee can return to the sign-in page and select Continue with Microsoft. If a former employee is rejoining and should regain access, treat it as an HR change first: their CLVR record needs to be active before Microsoft sign-in will work again. Re-enabling their Microsoft account on its own does not restore access, because the block lives in the CLVR record.
A bulk people-list import can also mark people as terminated if they are missing from the uploaded file. When you import, review the list of employees flagged as "not in the uploaded file" before confirming, so nobody is offboarded by accident.
An employee on a different domain has no Microsoft button
Microsoft single sign-on is tied to one email domain that your company configured, for example @company.com. Only employees whose work email is on that exact domain are offered Continue with Microsoft. Anyone on a different domain, like a contractor or a subsidiary using their own address, signs in with the standard options instead. This is expected, not a fault: their account works the same way once they are in.
The sign-in page works from the work email each person enters and matches its domain against your configured Microsoft sign-in domain. If the domain matches, the person sees the Microsoft sign-in notice and a single Continue with Microsoft button; if it does not, they see the standard options. Employees whose email is not on your Microsoft domain fall back to a sign-in link emailed to them (they select Send sign-in link), the one-time code in that same email, or email and password if your company is set up for password sign-in.
CLVR currently supports a single Microsoft sign-in domain per company. A second company domain cannot have its own Microsoft sign-in yet, even if both belong to the same organisation, so plan for everyone outside the configured domain to use the sign-in link instead. If covering a second domain matters to your company, raise it with your CLVR contact as a request: it is not something you can switch on yourself from the webapp today.
A setup link expired or is invalid
When your company sets up Microsoft single sign-on, your CLVR contact emails a one-time setup link to your IT team, who opens it to enter the Microsoft credentials. That link does not last forever, and it is meant to be used once. If your IT team opens it and sees an error instead of the setup form, a link can fail for a few reasons:
- It expired. Setup links are valid for 7 days from when they are sent. After that they stop working.
- It was already used. Once setup is completed with a link, that link is finished and cannot be opened again.
- It was replaced. When a setup link is successfully used, any other pending links for your company are revoked at the same time. If your CLVR contact deliberately revoked a link, it stops working too.
- The web address is incomplete. The link only works with the full setup token in the address. A truncated or hand-typed link is missing that token.
The message on the page tells you which case you are in. Invalid or expired link shows for an expired, used, or revoked link, and points you to ask your CLVR contact for a new one. Invalid link means the address is missing the setup token, which usually happens when a link is copied or forwarded and gets cut off.
If your IT team sees the Invalid link (missing setup token) message, ask them to open the link directly from the original email rather than pasting it, so the full address is preserved.
An old link cannot be reactivated, so the fix is always a fresh one: ask your CLVR contact to send a new setup link, have your IT team open it from the email and complete the form within 7 days, and once the credentials are saved, single sign-on is enabled and any older pending links stop working automatically.
Troubleshooting
- It works for some employees but not others. A redirect, permission, or secret problem affects everyone on the domain, so that is usually not the cause for a single person. If one person is blocked while colleagues sign in fine, check whether they are on a different email address, a second company domain, or a terminated account instead. For "no account found", add the affected colleagues the same way: each person needs their own employee record with their own Microsoft work email.
- The error started suddenly after months of working. Suspect an expired client secret first, then check whether anything changed in the Azure app registration.
- Microsoft shows its own message before the CLVR screen. Read that wording carefully and share it with your IT team. CLVR passes it through precisely because it is the most useful clue.
- The sign-in link still shows for the right domain. The setup likely did not save. Ask your IT team to confirm they reached Setup complete; if not, they may need a fresh setup link.
- A group of people on a second domain cannot sign in. Contact your CLVR contact, since only one SSO domain is supported per company.
- The sign-in link never arrives for someone falling back to it. Ask them to check spam and junk first. If links are reliably blocked by their email security, ask your CLVR contact whether their domain should move to email and password.