Setting up single sign-on (SAML)

Connecting your identity provider, verifying your domain, and enforcing SSO safely.

Updated Available on Agent Pro Agent Advanced Agent Enterprise

Settings → Single Sign-OnConfigure SAML single sign-on for your organization.

A paid feature, and owner-only. If you’re an Admin you won’t see it.

What you’ll need from your identity provider

FeedbackRobot supports SAML, so this works with Okta, Entra ID (Azure AD), Google Workspace, OneLogin and anything else that speaks SAML.

You’ll be asked for:

Field Where it comes from
IdP Entity ID (required) Your identity provider’s issuer ID
IdP SSO URL (required) The sign-in endpoint users are sent to
IdP certificate file The signing certificate, uploaded as a file
IdP SLO URL (optional) Single logout, if your provider supports it

FeedbackRobot gives you an ACS URL to paste into your identity provider — that’s the address it posts the assertion back to. You’ll be moving values in both directions, so it’s easiest to have both tabs open.

Verify your domain

Add your email domain, then verify it by DNS. You’ll see Domain added — now verify it via DNS until that’s done.

Domain verification is what makes SSO work automatically at sign-in: when someone enters a work email on a verified domain, they’re routed to your identity provider instead of being asked for a password.

You can add more than one domain, and remove one with Remove domain.

Enable it

Enable SSO turns it on. At this point SSO works but isn’t required — people can still sign in the normal way.

Test it before going further. Sign in with SSO from a private window and confirm you land in the right workspace.

Requiring SSO

Require SSO enforces it for everyone on your verified domains — no more password or magic-link sign-in.

This is the step to be careful with. Enforcing SSO while your identity provider is misconfigured can lock your whole team out, including you.

Before enforcing:

  1. Confirm SSO sign-in works end to end for at least one real user
  2. Confirm your domain shows as verified
  3. Save your recovery codes somewhere outside FeedbackRobot — these are your way back in if the identity provider becomes unavailable. A password manager or a printed copy in a safe; not an email to yourself on the domain you’re about to lock behind SSO
  4. Check the certificate isn’t near expiry — an expired IdP certificate breaks sign-in, and the screen warns you with Certificate expired

You can relax enforcement later with Make optional, and turn the whole thing off with Disable.

Certificate renewal

SAML certificates expire. When your identity provider issues a new one, upload it here before the old one lapses. This is the single most common cause of a working SSO setup suddenly failing, and it’s entirely predictable — put the expiry date in a calendar.

If people can’t sign in

  • Confirm the domain is verified
  • Confirm the certificate hasn’t expired
  • Confirm the user exists in the group your identity provider assigns to FeedbackRobot
  • Use a recovery code to get in, then disable enforcement while you investigate

Still stuck? Contact us — tell us your identity provider and what the error says.

Was this article helpful?

Still stuck? Talk to us — or open the chat in the corner.