Answers to common questions and solutions for issues you may encounter when setting up or using SSO and SCIM with BetaTesting.
Frequently Asked Questions
General
Which identity providers does BetaTesting support?
BetaTesting works with any identity provider that supports the SAML 2.0 standard. This includes Okta, Microsoft Entra ID (Azure AD), OneLogin, Google Workspace, Ping Identity, JumpCloud, and many others. We have a dedicated setup guide for Okta and a general guide that works with any SAML provider.
Do I need an Enterprise plan for SSO?
Yes. SSO and SCIM are available exclusively on BetaTesting Enterprise plans. Contact your account manager or our sales team for more information.
Can I use SSO for tester accounts too, or only admin accounts?
SSO works for all account types. Through role mapping, you can configure some IdP groups to grant admin-level access while others grant tester-level access. The default role (typically Tester) is applied when a user doesn't match any specific role mapping.
Does SSO replace password-based login?
For users whose email domains are configured for SSO, the SSO login flow is used instead of the standard email/password login. Existing users with matching email domains will be prompted to link their existing BetaTesting account when they first log in via SSO.
What happens to existing BetaTesting accounts when SSO is enabled?
Existing users whose email matches the SSO domain will be prompted to link their BetaTesting account the first time they use SSO. Their existing data, test history, and permissions are preserved. After linking, they'll use SSO for future logins.
SCIM
Do I need SCIM, or is SSO alone enough?
SSO alone is sufficient for many organizations. Without SCIM, user accounts are created automatically on first login (just-in-time provisioning). SCIM adds automated lifecycle management -- users are pre-created before their first login, automatically deactivated when removed from your IdP, and group memberships are synced in real time. SCIM is recommended if you need strict control over who can access BetaTesting.
What happens if SCIM is enabled and a user who isn't provisioned tries to log in?
They will be blocked. When SCIM is enabled, only users who have been provisioned through SCIM can log in via SSO. The user will see an error message indicating their account has not been provisioned and should contact their administrator.
Can I use SCIM without SSO?
No. SCIM provisioning requires an active SSO connection. You must set up SAML SSO first before enabling SCIM.
How quickly are SCIM changes reflected in BetaTesting?
SCIM changes are processed in real time. When your IdP sends a provisioning, deprovisioning, or group membership change, it is applied to BetaTesting immediately.
Role Mapping
What role do users get if they don't match any role mapping?
Users who don't match any configured role mapping receive the default role set for your SSO connection. This is typically the Tester role but can be changed by your BetaTesting account manager.
Are group name matches case-sensitive?
Yes. The group names in your IdP must match the role mapping configuration exactly, including case. For example, if your mapping is configured for "Admins" but your IdP sends "admins", the match will fail and the user will receive the default role.
Can a user have different roles in different test groups?
Yes. Role mappings can be scoped to specific test groups, allowing you to assign different access levels for different parts of your BetaTesting account. Contact your account manager to set up group-scoped mappings.
Troubleshooting
SSO login fails - user is not redirected to the identity provider
Possible causes:
The SSO connection may not be enabled yet. Contact your BetaTesting account manager to verify it is active.
The SSO login link may be incorrect. Make sure you're using the link provided by your account manager.
The user's email domain may not match the allowed domains configured for your SSO connection.
User is redirected to the IdP but gets an error after authenticating
Possible causes:
Mismatched SAML values: The Assertion Consumer Service URL or Entity ID in your IdP app may not match what BetaTesting expects. Double-check that you updated your IdP with the exact values provided by BetaTesting in Step 3 of the setup process.
Certificate issue: Your IdP's signing certificate may have changed or expired. Download a fresh certificate from your IdP and share it with your BetaTesting account manager.
User not assigned: The user may not be assigned to the BetaTesting app in your IdP. Check the Assignments tab of your IdP application.
User logs in but gets the wrong role
Possible causes:
Group name mismatch: The group names sent by your IdP must match the role mapping configuration exactly (case-sensitive). Check with your BetaTesting account manager to verify the configured group names match your IdP groups.
Missing group attribute: Your SAML app may not be sending group information. Verify that you configured a Group Attribute Statement in your IdP (see the SSO setup guides).
Priority conflict: If the user belongs to multiple mapped groups, the highest-priority rule wins. Contact your account manager to review the priority ordering.
SCIM groups not pushed: If you're using SCIM, make sure you've pushed the relevant groups from your IdP (see Set Up SCIM with Okta, Step 4).
SCIM "Test Connector Configuration" fails in Okta
Possible causes:
Incorrect SCIM base URL: Verify the URL is exactly as provided by your BetaTesting account manager (e.g.,
https://betatesting.com/api/scim/v2)Invalid Bearer token: Make sure the token is copied exactly with no trailing spaces. Contact your account manager for a new token if needed.
Connectivity issue: Your IdP must be able to reach BetaTesting's SCIM endpoint over the internet. Check that there are no firewall or proxy rules blocking outbound requests.
SCIM-provisioned users can't log in
Possible causes:
User was deprovisioned: If the user was previously unassigned in your IdP, their BetaTesting account may be deactivated. Re-assign the user in your IdP to reactivate their account.
Email domain mismatch: The user's email may not match the allowed domains for the SSO connection.
SSO connection not enabled: The SSO connection itself may be disabled. Contact your BetaTesting account manager.
Users see "Your account has been deactivated"
This means the user was deprovisioned via SCIM (either manually unassigned or set to inactive in your IdP). To restore access:
In your IdP, re-assign the user to the BetaTesting app
Your IdP will send a SCIM provisioning request to re-create/reactivate the user
The user should then be able to log in via SSO
Users see "Your account has not been provisioned"
This means SCIM is enabled for your SSO connection, but the user hasn't been provisioned. The user must be assigned to the BetaTesting app in your IdP before they can log in. Assign them in your IdP and Okta will automatically provision them.
Getting Help
If you're experiencing an issue not covered here, contact your BetaTesting account manager. When reporting issues, it's helpful to include:
The email address of the affected user
The identity provider you're using (e.g., Okta, Azure AD)
A description of what happens (error message, unexpected behavior)
When the issue started
Any recent changes to your IdP configuration