Rolling Out SSO and Fixing Sign-In Problems

A safe rollout plan for single sign-on, what each sign-in error message means, and how to fix the common setup mistakes.

This page helps you switch your team to single sign-on without locking anyone out, and fix things when a sign-in doesn't work.

A safe rollout plan

  1. Set it up with auto-provisioning off. Only people who already have a Plenix account can use SSO.
  2. Test with your own account in a private browser window.
  3. Ask two or three colleagues to try it, ideally one on a phone.
  4. Add your allowed email domains. This makes sure personal or other-company addresses can't use your SSO.
  5. Turn on auto-provisioning only if you want new starters to get a Plenix account the first time they sign in. Pick a low access role, such as Viewer, and promote people afterwards.
  6. Tell your team to use the Sign in with … button from now on.
  7. Keep at least one administrator who can sign in with a password and has Plenix two-factor set up. That's your way back in if the identity provider is ever down.

What people see when sign-in fails

When SSO can't sign someone in, they're returned to the login page with one of these messages:

Message on the login pageWhat it meansHow to fix it
Single sign-on isn't enabled for this workspaceSSO is switched off or was removed.Switch on Enable single sign-on in Settings β†’ SSO.
There's no Plenix account for this identityNobody in Plenix has that email address, and auto-provisioning is off.Invite the person in Settings β†’ Users with the same email, or turn on auto-provisioning.
This email domain isn't allowedThe email isn't on one of your Allowed email domains.Add the domain, or check the person is using their work account.
This account is unavailableThe Plenix account is deactivated or locked.Reactivate or unlock it in Settings β†’ Users.
No free user seatsAuto-provisioning needed a seat and your plan has none left.Free up a seat or add users to your plan in Billing.
Single sign-on failedSomething in the setup didn't match.Check Last failed sign-in on the SSO page for the exact reason (see below).

Reading "Last failed sign-in"

Settings β†’ SSO shows the reason for the most recent failure. The most common ones:

  • Issuer mismatch. The Issuer URL in Plenix isn't exactly what your provider reports. For Microsoft it must be https://login.microsoftonline.com/<your tenant ID>/v2.0, with /v2.0 and without a trailing slash. For Okta, check whether you use the org issuer or a custom authorisation server.
  • Invalid client / invalid secret. The client secret is wrong or has expired. For Microsoft, make sure you copied the secret's Value, not its Secret ID. Create a new secret and paste it in.
  • Redirect URI mismatch. Your provider shows an error before you even get back to Plenix (Microsoft: AADSTS50011). The Redirect URI registered in your provider must match the one in Plenix exactly. Copy it again with the copy button.
  • No email in the response. Your provider didn't send an email address. For OIDC, check the email scope or permission is allowed. For SAML, set the Name ID to the user's email address.
  • Email not verified. Some providers mark addresses as unverified. Verify the address in the provider, or use the user's primary email.
  • Signature or certificate problem (SAML). The assertion isn't signed, or the certificate in Plenix is out of date. Use the IdP metadata URL so certificates update automatically, or paste the new certificate.
  • Wrong audience or entity ID (SAML). The Entity ID / Audience in your provider must match the Plenix Entity ID exactly.
  • Request expired. The sign-in took too long, or the browser blocked cookies. Start again from the Plenix login page. Don't use the browser's back button.

Other common questions

Someone clicks the Plenix tile in My Apps / the Okta dashboard and it fails. Launching Plenix from your provider's app portal isn't supported yet. Ask people to bookmark your Plenix login page instead. For Microsoft and Okta you can set the tile's sign-on URL to your login page so the tile opens it.

Can SSO set people's roles from their groups? Not yet. Your provider decides who may sign in. Roles are managed in Settings β†’ Users.

Do people still need Plenix two-factor? Only if Also require Plenix two-factor is on. It's on by default. Turn it off only if your provider already enforces MFA for this app.

Someone left the company. Disable them in your identity provider, which stops SSO straight away, and deactivate them in Settings β†’ Users so their Plenix password stops working too.

Where can I see who signed in? Every SSO sign-in and every account created by auto-provisioning is recorded in the audit log.

Where to go next

Was this article helpful?

Rolling Out SSO and Fixing Sign-In Problems β€” Integrations & Connectors | Plenix Cloud Docs