Single sign-on lets your team sign in to BetaTesting with the work identity they already use, instead of another password to keep track of. You connect your identity provider once, decide which email domains are allowed in, and map your provider's groups to BetaTesting roles so people land on the right level of access the first time they sign in.
This pays off as soon as more than a few people share your BetaTesting account. Your security team gets one place to grant and revoke access. A new researcher joining the product team gets read only or full admin automatically, based on a group they are already in, with no request to file. When someone leaves, removing them in your identity provider removes their way in to BetaTesting.
Single sign-on is an Enterprise capability. Enterprise is our plan for mid-market and enterprise customers who need advanced features, customization, and security, so single sign-on may not be available on your account.
What you set up yourself
You run setup from BetaTesting. Open Integrations from your company menu, then open the Single Sign-On tab. From there you can:
Run a four step setup wizard that collects your identity provider, allowed email domains, default role, and group to role mappings.
Change any of those settings later, whenever you need to.
Add, edit, delete, and drag to reorder your role mappings.
Turn the connection on and off yourself.
Run more than one connection, for example one per business unit or one per identity provider.
Our team still does the work on our side after you submit the wizard. That is where the signing certificate exchange and your final SAML values come from.
Before you start
A company subdomain. Single sign-on needs one so we can check that your allowed email domains belong to you, and it becomes your sign-in URL, for example acme.betatesting.com/login. If you have not claimed one, the Single Sign-On tab shows Claim your subdomain first and an Open Branding settings button.
Super admin access on your BetaTesting company account. Other admins cannot open the Integrations page.
Administrator access to your identity provider.
How setup works
Setup is mostly yours, with one handoff in the middle.
You create a SAML application in your identity provider and collect its sign-on URL, issuer, and X.509 signing certificate.
You run the setup wizard in BetaTesting and click Submit setup.
Your connection shows the status Awaiting setup while our team builds it, usually within one business day. Your account manager asks you to send the signing certificate securely, and sends back your Assertion Consumer Service URL and Entity ID.
You paste those two values into your identity provider application and assign your users to it.
You turn on the enable toggle on the connection. The status changes to Live and your team can sign in.
For step by step instructions, follow the setup guide for your provider.
What the statuses mean
Awaiting setup: you submitted the wizard and our team is building the connection. You can keep editing your settings and role mappings while you wait.
Draft: the connection is built but switched off. Nobody signs in through it yet.
Live: the connection is on and in use.
Blocked: a recent sign-in attempt failed. Review your identity provider configuration before enabling it again.
Roles and role mapping
Single sign-on grants one of four BetaTesting roles: Full admin, Support only, Read only, and Tester. Everyone who signs in gets the Default role for new members you chose in the wizard, unless a role mapping matches them.
A role mapping says: when the claim your provider sends contains this value, grant this role. If someone matches more than one mapping, the mapping nearest the top of the list wins, and you set that order by dragging rows. The top row is labelled Highest priority.
You manage all of this yourself on the connection, in the Map IdP claims to BetaTesting roles section. Roles are worked out again on every sign-in, so a group change in your provider takes effect the next time the person signs in. For more on the roles themselves and how mappings are applied, see SSO Role Mapping & Permissions.
Single sign-on and SCIM
BetaTesting also supports SCIM 2.0 provisioning on top of single sign-on, so your identity provider creates accounts before anyone signs in, deactivates them when you unassign the person, and keeps group memberships in sync. SCIM needs an active single sign-on connection first, and once it is switched on for a connection, only people your provider has provisioned can sign in. SCIM Provisioning Overview covers how it works and what you need to set it up.
Supported identity providers
Anything that speaks SAML 2.0 works. The setup wizard lists Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, JumpCloud, and Something else, where you type the name of your provider. Picking Something else does not limit anything, it just tells our team what to expect.
Things to know
Allowed email domains are optional in the wizard. Setting them is what lets your subdomain sign-in page recognize an address and send that person to your identity provider, so most teams set them.
Each allowed domain has to share a root with your company subdomain. With the subdomain acme, both acme.com and eu.acme.com are accepted, and acmegroup.com is not.
The enable toggle only appears once our team has finished provisioning. Until then the connection cannot be switched on.
Claim values are matched exactly, including capitalization. A mapping for Admins does not match a group your provider sends as admins.
Removing a connection takes away SSO access for the people who signed in through it. Their BetaTesting accounts and history stay, they just cannot sign in through SSO any more.
Group scoped mappings, where a role applies only inside one test group, are not part of the self-serve editor. Ask your account manager if you need them.
Next steps
Set up SAML SSO with Okta, if Okta is your provider.
Set up SAML SSO with any identity provider, for every other SAML 2.0 provider.
Set up SCIM with Okta, if you want automated provisioning as well.
SSO and SCIM FAQ and troubleshooting, if something is not working.