Going Live with SSO

A safe SSO rollout turns SSO on as Optional first, lets a pilot group sign in, and only then switches to Required — while the organization owner account keeps password sign-in as a way back in.

Updated 2026/10/19

Recommended rollout

Test — Test SSO has passed (see Testing Your SSO Connection).
Turn on as Optional — enforcement Optional, switch on, Save. The Continue with SSO button appears on your sign-in page; passwords keep working.
Pilot — ask a small group (IT, HR, a few managers) to sign in with SSO for a few days. Check the activity log (below) for failures.
Announce — tell everyone how to sign in from now on (template below).
Switch to Required — enforcement Required, Save. Users on your domains now sign in only through your identity provider.

What your users see

Your organization's sign-in page shows Continue with SSO under the usual form.
When someone types an email on one of your SSO domains, the page says “Your organization signs in with single sign-on” and highlights the SSO button. The email is passed to your identity provider as a hint, so people often do not have to type it again.
Under Required, the password field is hidden for such emails; pressing Enter continues with SSO. A small Sign in with a password instead link remains for the organization owner.
Under Required, a user governed by SSO who signs in with their old username and password is told that their account signs in with single sign-on, and is shown the SSO button.
After signing in at the identity provider, people land in TestInvite — on a specific page when the sign-in started from a Sign-in URL with a destination.

Message template for your employees

From [date], sign in to TestInvite with your company account. Open [your TestInvite sign-in page or Sign-in URL], click Continue with SSO (or type your work email), and sign in as you do for email. You do not need a separate TestInvite password any more. Questions: [IT contact].

Links and app tiles

Your Sign-in URL (https://www.testinvite.com/api/v1/auth/sso/<ORG-ID>/initiate) starts SSO directly. Use it on your intranet, in onboarding emails and as the target of identity provider app tiles (Microsoft My Apps, Okta dashboard, Google app launcher). Add ?returnTo=/app/… to land on a specific TestInvite page.

Monitoring sign-ins

Every SSO sign-in — successful or not — is recorded in Organization → Activity as Single sign-on sign-in, with the email, the protocol, whether it started at the identity provider, and for failures the error code. Users created automatically appear as User created.

Day-to-day operations

Situation	What to do
Someone joins	Assign them to the TestInvite application in your identity provider. With automatic user creation on, their TestInvite user is created at their first sign-in.
Someone leaves	Disable them (or remove the assignment) in your identity provider: they can no longer sign in with SSO. Also deactivate their TestInvite user — deactivated users cannot sign in by any method. Their results stay in TestInvite.
Someone's name changes	Change it in your identity provider; TestInvite updates it at the next SSO sign-in.
Someone's email changes	TestInvite matches people by email, and an SSO-managed user's email is read-only in TestInvite. After the change, the next SSO sign-in is treated as a new person: with automatic user creation on, a new user is created (otherwise the sign-in is refused). The old user keeps its results; deactivate it.
The identity provider renews its certificate	With a metadata URL: nothing to do. Otherwise add the new certificate in TestInvite before the switch, then remove the old one. TestInvite highlights certificates that expire within 30 days.
The OIDC client secret expires	Create a new secret in your identity provider, enter it in TestInvite, run Test SSO, Save.
You change identity provider settings	Run Test SSO with the new settings, then Save. SSO keeps working with the saved settings until then.

Rolling back

Back to Optional: set enforcement to Optional and Save — passwords work again for everyone who has one.
Turn SSO off: switch it off and Save. The SSO button disappears. Users created by SSO never had a TestInvite password: they can set one with Forgot password on your sign-in page, when password reset is allowed in your portal's sign-in settings.
If your identity provider is down or misconfigured: the organization owner can always sign in with the owner account's email and password (on the TestInvite sign-in page, or via Sign in with a password instead on your organization's page) and change the settings.

Go back