BetaTesting can automatically assign roles to SSO users based on their group memberships in your identity provider (IdP). This ensures your team members get the right level of access in BetaTesting without manual configuration.
How Role Mapping Works
When a user logs in via SSO, BetaTesting determines their role by checking which IdP groups they belong to. Your BetaTesting account manager configures role mapping rules that link specific IdP group names to BetaTesting roles.
Example: If your IdP has a group called "BT-Admins" and a mapping rule assigns that group to the BetaTesting Admin role, any user who belongs to "BT-Admins" will automatically receive Admin access in BetaTesting.
Available BetaTesting Roles
Role mappings can assign users to the following BetaTesting roles:
Role | Access Level | Description |
Full Admin | Company-wide | Full management access to all tests, settings, and team members across the entire company account |
Support | Company-wide | Can manage tests and tester communications, but cannot modify company settings or billing |
Read-Only | Company-wide | View-only access to all tests and data across the company |
Group Admin | Group-scoped | Full Admin access, but limited to tests within a specific test group |
Group Support | Group-scoped | Support access limited to tests within a specific test group |
Group Read-Only | Group-scoped | Read-only access limited to tests within a specific test group |
Tester | N/A | Default role -- the user participates in tests as a tester, with no company admin access |
How Groups Are Sent to BetaTesting
There are two ways IdP group information reaches BetaTesting, depending on whether you have SCIM enabled:
Without SCIM (SSO Only)
Group memberships are sent as claims in the SAML assertion each time the user logs in. You configure this by adding a Group Attribute Statement in your SAML app (see the SSO setup guides for details).
Roles are recalculated on every login
Changes to group membership in your IdP take effect the next time the user logs in
With SCIM
Group memberships are pushed to BetaTesting via the SCIM Groups API and stored persistently. When the user logs in via SSO, BetaTesting uses the stored SCIM group memberships for role resolution.
Roles are updated in real-time as your IdP pushes group changes via SCIM
Users don't need to log out and back in for role changes to take effect
This is the recommended approach for organizations that need tight access control
Setting Up Role Mappings
Role mappings are configured by your BetaTesting account manager. To set up mappings:
Decide which IdP groups map to which BetaTesting roles
For example:
IdP Group Name | BetaTesting Role | Scope |
| Full Admin | Company-wide |
| Support | Company-wide |
| Read-Only | Company-wide |
| Group Admin | Specific test group |
Share this mapping with your BetaTesting account manager
Your account manager configures the rules in BetaTesting, linking each group name to the corresponding role
Priority and Conflict Resolution
When a user belongs to multiple mapped groups, BetaTesting resolves conflicts using a priority system:
Each mapping rule has a priority number (lower number = higher priority)
The highest-priority matching rule determines the user's role
If no mapping rules match any of the user's groups, the user receives the default role configured for your SSO connection (typically Tester)
Example: A user belongs to both "BT-Admins" (priority 1, maps to Admin) and "BT-Support" (priority 2, maps to Support). The Admin role wins because it has a higher priority.
Default Role
Every SSO connection has a default role that applies when:
The user doesn't belong to any mapped groups
No mapping rules match the user's group memberships
Group attributes are not configured in your IdP
The default role is typically Tester, meaning users without a specific group mapping will have tester-level access. Your BetaTesting account manager can change this default if needed.
Group-Scoped Access
For organizations that organize their BetaTesting work into test groups, role mappings can be scoped to specific groups:
Company-wide roles give access across all tests in the company
Group-scoped roles restrict access to tests within a specific test group
This is useful when different teams within your organization need access to different subsets of your BetaTesting projects.
Best Practices
Use descriptive group names - Name your IdP groups clearly (e.g.,
BetaTesting-Adminsrather thanGroup1) to make mappings easy to understandStart with the default role - Keep the default role as Tester so unrecognized users get the lowest access level
Test with a dedicated user - Before rolling out to your entire team, test role mapping with a single user to verify correct assignment
Keep groups consistent - The group names in your IdP must match the role mapping configuration exactly (case-sensitive). Any changes to group names in your IdP will need to be updated in BetaTesting
Use SCIM for real-time sync - If you need role changes to take effect immediately (without the user logging out and back in), enable SCIM provisioning
Making Changes
To update role mappings:
Add a new mapping - Contact your BetaTesting account manager with the IdP group name and desired BetaTesting role
Change a mapping - Contact your account manager to update the role for an existing group
Remove a mapping - Contact your account manager to remove a mapping; affected users will fall back to the default role on their next login (SSO only) or immediately (SCIM)