Confirming and maintaining SSO after setup
How to confirm Microsoft sign-in went live for your domain, change the domain or Azure credentials later, rotate an expired client secret, and get the domain format right.
Once your IT contact finishes the Microsoft sign-in setup form, there is nothing for your HR team to publish or switch on separately: sign-in turns on the moment the form is saved. This guide covers everything after that first save: confirming SSO is live for your domain, changing the domain or Azure credentials later, rotating the client secret when it expires, and the rules for the Email domain field itself.
There is no edit screen for Microsoft single sign-on inside CLVR Benefits. Every change after the original setup (a new domain, new credentials, or a fresh secret) is made by re-submitting the same one-page form through a new setup link, not by editing a setting.
What IT sees when setup saves
On the setup page, IT fills in the domain and the three credential fields, then selects Save and enable. When the save succeeds, the page replaces the form with a confirmation:
- A Setup complete message, and
- The line "Microsoft sign-in is now enabled. Employees can sign in with their work account."
If IT sees that confirmation, the configuration is saved and active. There is no further activation step, and your HR team does not need to do anything in the webapp to finish it.
Verify it from the sign-in screen
You can confirm it yourself in under a minute:
Open the CLVR Benefits sign-in page.
In the Sign in with Email field, enter an employee email on your configured domain (for example name@company.com) and continue.
When Microsoft sign-in is live for that domain, the form swaps the Send sign-in link button for a notice titled Microsoft sign-in that reads "Your company uses Microsoft sign-in", with a single Continue with Microsoft button below it. No magic link or password option appears for that domain.
That swap is the signal that SSO is active. CLVR checks the domain as you type and again when you continue, so the Microsoft option appears as soon as the email matches your configured domain.
Test with a real employee email that is already in CLVR and still employed. Microsoft sign-in only completes for an active (non-terminated) employee on the configured domain, so a made-up address will not finish the sign-in even when the notice appears.
Domain format rules
The setup form asks for an Email domain. This is the part of your work email address after the @ sign, and CLVR uses it to decide which employees sign in with Microsoft. Getting the format right matters.
Enter the domain on its own, with no @ sign and no name in front of it.
- Correct:
company.com - Wrong:
name@company.com
The field is labelled Email domain and shows company.com as the placeholder. As soon as you type a value, a short note appears under the field reading "Employees with @company.com will use Microsoft sign-in", so you can confirm it matches the addresses your employees actually use.
The form checks the value before saving and rejects anything that does not look like a real domain:
- No @ sign. Entering a full address such as
name@company.comis rejected with "Enter the domain without @ (e.g. company.com)". - It must contain a dot. A single word with no dot is rejected with "Domain must contain a dot (e.g. company.com)". A subdomain such as
mail.company.comis fine because it still contains a dot. - Allowed characters only. Letters, numbers, hyphens, and dots are accepted. Anything else (spaces, underscores, slashes) is rejected with "Domain can only contain letters, numbers, hyphens and dots".
The domain is always stored in lowercase, and at sign-in CLVR compares an employee's email domain against it without caring about case. So Company.com, COMPANY.COM, and company.com all behave the same, and an employee whose address happens to use capital letters will still be matched.
Use the domain your employees already have in their work email. If everyone signs in as firstname.lastname@company.com, the domain to enter is company.com.
In most setups, your CLVR contact fills in the domain for you when they create the setup link. In that case the Email domain field is shown but locked, so your IT team cannot change it, and the format checks above have already been handled. Your IT team only needs to complete the Azure credential fields (Application (client) ID, Directory (tenant) ID, and Client secret) and choose Save and enable. If the locked domain is wrong, do not work around it. Ask your CLVR contact to issue a new setup link with the correct domain.
One domain per company
Each company can have one SSO domain today. Employees whose email is on that domain get the Continue with Microsoft button; everyone else keeps the sign-in method their address already resolves to, which for most people is a one-time sign-in link sent by email (or email and password, if your company is set up for that). If your organisation uses several email domains, talk to your CLVR contact about which one to enable.
Updating or changing your SSO domain or credentials
Because there is no edit screen, you change a live SSO configuration by submitting a fresh setup link, not by editing a setting. The configuration that gets replaced is the email domain plus the Azure Application (client) ID, Directory (tenant) ID, and Client secret.
Ask your CLVR contact for a fresh setup link
To change anything about an existing SSO setup, start by asking your CLVR contact to send a new setup link for your company.
- Setup links are valid for 7 days.
- If you are changing the domain, tell your CLVR contact the new domain when you ask, because the domain is usually set on the link itself and shown locked on the form. A link created with the old domain cannot be used to switch to a new one.
The Email domain field on the setup form is shown but locked when your CLVR contact filled it in on the link. That is why a domain change has to come from a new link with the correct domain, rather than from IT editing the field.
What IT enters on the new link
Your IT contact opens the new link and lands on the Microsoft OAuth setup form, then enters the values that should apply going forward:
Confirm the Email domain shown on the form is the one you want. If it is locked to the wrong value, stop and ask your CLVR contact for a corrected link rather than working around it.
Enter the Application (client) ID, Directory (tenant) ID, and Client secret from your Azure app registration. To change only one of these, IT still re-enters all of them, because the form saves a complete configuration.
Select Save and enable. The form shows a Setup complete confirmation: "Microsoft sign-in is now enabled. Employees can sign in with their work account."
When the save succeeds, the new configuration replaces the old one immediately. There is no separate publish or activation step.
Saving revokes other pending links
When IT saves a new configuration, CLVR automatically marks that link as used and revokes any other pending setup links for your company. So if more than one link was issued, only the one that was just saved counts, and there is no stale link left active. If you need to make another change afterwards, ask your CLVR contact for a new link.
Changing the domain changes who uses Microsoft sign-in
The domain decides which employees see Continue with Microsoft. Employees whose work email is on the configured domain get Microsoft sign-in; everyone else keeps the method their address already resolves to (for most people that is a one-time sign-in link sent by email, or email and password if your company is set up for that). Before changing the domain, confirm the new value matches the addresses your employees actually use, so you do not move sign-in to a domain nobody is on.
After IT saves, test sign-in for an employee on the new domain using the same sign-in-screen check described above: enter an address on the new domain and confirm the Continue with Microsoft button appears and signs you in cleanly.
Rotating an expired client secret
Azure client secrets have an expiry date. When the secret behind your Microsoft single sign-on lapses, sign-in stops working for everyone on your domain until IT creates a new one and you re-enter it.
How you know the secret has expired
The first sign is usually employees reporting that Continue with Microsoft no longer signs them in. After they reach Microsoft, they land back on the CLVR Benefits sign-in page with:
Something went wrong with Microsoft sign-in. Please try again.
This is a generic message, so an expired client secret is only one possible cause. Before assuming it is the secret, it is worth ruling out the other usual suspects (a mistyped redirect URI, or missing admin consent for the User.Read permission). The expiry date IT set when creating the secret is the quickest thing to check: if that date has passed, the secret is the problem.
There is no field inside CLVR Benefits to update credentials yourself. Replacing a secret always goes through a fresh setup link, the same one-page form your IT contact used during the original setup.
What IT does in Azure
Your IT contact creates a brand-new client secret on the same app registration they set up originally:
In the Azure Portal, open the app registration and go to Certificates & secrets, then choose New client secret.
Copy the secret Value straight away (not the Secret ID). Azure shows the value only once, so if they navigate away before copying it, they have to create another one.
Note the new expiry date so you can renew the secret before it lapses next time.
Nothing else in Azure needs to change. The domain, Application (client) ID, and Directory (tenant) ID stay the same: only the secret is new.
Re-enter the new secret in CLVR Benefits
Because there is no edit screen for SSO, you re-enter the credentials through a fresh setup link:
- Ask your CLVR contact to send a new setup link for your company. Links are valid for 7 days.
- IT opens the link and lands on the Microsoft OAuth setup form.
- They enter the same Email domain, Application (client) ID, and Directory (tenant) ID as before, plus the new value in the Client secret field.
- They select Save and enable.
Saving replaces the old configuration and automatically revokes any other pending setup links for your company, so there is no stale link left active. Have one employee on the SSO domain try signing in again with Continue with Microsoft. A clean sign-in confirms the new secret is live. If it still fails, the cause is most likely something other than the secret, so move on to the redirect URI and consent checks.
Troubleshooting
- The sign-in screen still shows the sign-in link or password option for that domain. The setup may not have saved. Ask your IT contact to confirm they reached the Setup complete confirmation. If they did not, the setup link may need to be reopened or a fresh one requested.
- The Microsoft notice appears but sign-in does not complete. Check that the email belongs to a current employee in CLVR. Terminated employees and addresses that are not in CLVR are blocked even when the Microsoft option shows.
- Nothing changed and IT says the form saved. Make sure you are testing with an email on the exact domain that was configured. A colleague on a different domain will still see their own sign-in method.
- The form rejects the domain entered. Re-read the error under the field. The most common causes are pasting a full email address (drop the part before and including the @ sign) or a value with no dot in it.
- The new domain is locked to the wrong value. Do not work around it. Ask your CLVR contact for a fresh link with the correct domain.
- Employees on the old domain can no longer sign in with Microsoft. That is expected after a domain change. They now use whatever method their address resolves to, usually a sign-in link by email. If they should keep Microsoft sign-in, the new domain was probably wrong, so ask your CLVR contact to issue a corrected link.
- The setup link expired before IT could use it. Links last 7 days. Ask your CLVR contact for a new one.
- Sign-in still fails after saving new credentials. The cause may be in Azure rather than CLVR. Ask IT to confirm the redirect URI on the app registration and that admin consent for the User.Read permission is in place.
- The new secret was lost before copying. Azure shows the Value only once. IT simply creates another New client secret under Certificates & secrets and copies it immediately.
- You want to avoid the secret expiring next time. Ask IT to record the secret's expiry date and renew it before that date, rather than waiting for sign-in to break.