Skip to main content

SCIM Provisioning — Users & Groups

SCIM (System for Cross-domain Identity Management) lets your Identity Provider (IDP) automatically manage users and groups within your TestMu AI organization — no manual account setup required.

CapabilityWhat it does
User ProvisioningAuto-create, update, and deactivate user accounts
Group ProvisioningSync IDP groups and map them to TestMu AI teams, concurrency groups, or sub-orgs
Role AssignmentSet organization roles (Admin / User / Guest) from your IDP

SSO is required. If you haven't set up SSO yet, see Getting Started with SSO first.


Setup​

What you need: Enterprise plan, SSO configured, Admin access, and an IDP that supports SCIM 2.0 (Okta, Azure AD, JumpCloud, etc.).

Step 1 — Copy SCIM Credentials​

Go to Settings > Organization Settings > Security tab. Copy the SCIM Base URL and Bearer Token.

SCIM Base URL and Bearer Token

Step 2 — Configure Your IDP​

Paste the SCIM Base URL and Bearer Token into your IDP's provisioning settings.

Full walkthrough: Okta SCIM Guide

  1. Applications > your TestMu AI app > Provisioning tab > Configure API Integration
  2. Check Enable API Integration, paste credentials, click Test API Credentials > Save
  3. Under To App, enable: Create Users, Update User Attributes, Deactivate Users
  4. Assignments tab > assign users or groups
  5. (For groups) Push Groups tab > Push Groups > Find by name or rule
tip

Member changes in pushed Okta groups are automatically synced to TestMu AI.


User Provisioning​

How It Works​

ScenarioWhat happens
New user (email doesn't exist)Account created and added to your org
Existing user (same org)Attributes (role, active) updated
Existing user (different org)Not provisioned — invite via team invite first

Schema & Attributes​

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User"
  ],
  "userName": "[email protected]",
  "active": true,
  "name": { "givenName": "Jane", "familyName": "Doe", "formatted": "Jane Doe" },
  "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User": {
    "OrganizationRole": "User",
    "LambdatestGroup": "Engineering"
  }
}

Standard Attributes

AttributeRequiredNotes
userNameYesMust be a valid email. Cannot be changed after creation.
activeYestrue = enabled, false = deactivated
nameYesgivenName, familyName, formatted

Custom Attributes (LambdaTest Extension)

These attributes are part of the urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User extension schema. To send them from your IDP, add this schema URN to your IDP's custom attribute configuration.

AttributeRequiredValuesNotes
OrganizationRoleNoAdmin, User, GuestSets the user's organization role. Defaults to User if not provided.
LambdatestGroupNo(concurrency group name)Assigns the user to a concurrency group by name. The group must already exist. Contact support to enable concurrency groups.

For PATCH operations, use the fully qualified SCIM path:

  • OrganizationRole: urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User:OrganizationRole
  • LambdatestGroup: urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User:LambdatestGroup

What can be updated: OrganizationRole, LambdatestGroup, and active can be updated via SCIM. userName is immutable after creation. name can only be changed from TestMu AI Account Settings.

User API Operations​

Request: POST https://auth.lambdatest.com/api/scim/Users

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User"
  ],
  "userName": "[email protected]",
  "active": true,
  "name": { "givenName": "Jane", "familyName": "Doe", "formatted": "Jane Doe" },
  "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User": {
    "OrganizationRole": "User",
    "LambdatestGroup": "Engineering"
  }
}

Response: 201 Created

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User"
  ],
  "id": "23123",
  "userName": "[email protected]",
  "active": true,
  "name": { "givenName": "Jane", "familyName": "Doe", "formatted": "Jane Doe" },
  "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:User": {
    "OrganizationRole": "User",
    "LambdatestGroup": "Engineering"
  }
}

Group Provisioning​

Quick Start

Push groups from your IDP → approve the mapping in the SCIM Group Provisioning dashboard → members are synced automatically.

How It Works​

Groups and members are stored as soon as your IDP pushes them — even before any mapping is configured. Mapping only controls where members are assigned.

Step 1 — Your IDP (automatic)
Groups & members pushed via SCIM
↓
Step 2 — LambdaTest (automatic)
Group stored & roles applied to members
Members get roles immediately, even without mapping
↓
Step 3 — Admin (manual) or Mapping Rules (automatic)
Group mapped to a LambdaTest entity
↙
↓
↘
Team
Additive
Multiple teams allowed
Concurrency Group
Exclusive
User can only belong to one
Sub-Organization
Exclusive
User can only belong to one

Enabling & Disabling​

note

Group provisioning is not enabled by default. Reach out to our 24/7 chat support or email [email protected] to get it activated for your organization.

Once activated, you can control it from Settings > Organization Settings > Security > SCIM Group Provisioning.

When toggled OFF: New IDP group operations (create/update/delete) are rejected with 403. Existing groups, mappings, and assignments are preserved — nothing is deleted. Toggle back ON to resume syncing.

Group Schema & Attributes​

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:Group",
    "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:Group"
  ],
  "displayName": "eng-backend",
  "members": [{ "value": "12345" }, { "value": "67890" }],
  "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:Group": {
    "LambdatestRoles": ["User"]
  }
}

Standard Attributes

AttributeRequiredNotes
displayNameYesMust be unique within your org
membersNoArray of { "value": "<user_scim_id>" }

Custom Attributes (LambdaTest Extension)

These attributes are part of the urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:Group extension schema. To send them from your IDP, add this schema URN to your IDP's custom attribute configuration.

AttributeRequiredValuesNotes
LambdatestRolesNoAdmin, User, GuestAssigns organization roles to all members of the group. Highest role wins if a user is in multiple groups.

For PATCH operations, use the fully qualified SCIM path:

  • LambdatestRoles: urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:Group:LambdatestRoles

Mapping Groups to LambdaTest Entities​

Once a group is pushed, it needs to be mapped to tell TestMu AI what to do with its members. Select your target entity type below to see the details relevant to you:

Feature Activation

Teams, Concurrency Groups, and Sub-Organizations are not enabled by default. Reach out to our 24/7 chat support or email [email protected] to get them activated for your organization before mapping groups to these entities.

Teams are additive — a user can belong to multiple teams at once, so there are no conflicts.

Auto-createYes — if the team doesn't exist, it's created automatically
On member removalRemoved from team (unless another SCIM group also maps them there)
On group renameTeam is automatically renamed to match the IDP group name
ConflictsNone — teams are never exclusive

This is the simplest and most common mapping. If you're just starting out, Team is the recommended choice.

A single SCIM group can only be mapped to one TestMu AI entity (one team, one concurrency group, or one sub-org). To assign the same users to multiple entities, use separate IDP groups.

Mapping statuses: Pending → Approved / Auto-Approved (members synced) or Rejected (no sync). If no mapping rule matches, the group stays Pending until an admin maps it manually.

To map manually: Go to SCIM Group Provisioning dashboard > click a Pending group > select target type and entity > Approve.

Mapping Rules (Automatic Mapping)​

Instead of mapping each group manually, create rules that auto-match groups by name.

Matches group names starting with a pattern (case-insensitive).

eng- matches eng-backend, eng-frontend, ENG-DevOps

Each rule has an auto-approve toggle:

  • ON → finds (or creates) the target entity by name → mapping approved → members synced immediately.
  • OFF → creates a Pending mapping → admin approves manually.

Rules are evaluated by priority (highest first). First match wins. If no rule matches, the group stays Pending until an admin maps it manually.

PriorityRuleTargetAuto-ApproveExample match
3Prefix: eng-TeamONeng-backend → auto-approved Team
2Prefix: qa-TeamONqa-mobile → auto-approved Team
1Match AllConcurrency GroupOFFdesign-ops → Pending

To create a rule:

  1. Go to SCIM Group Provisioning dashboard
  2. Click Add Mapping Rule
  3. Select a rule type (Prefix, Regex, or Match All)
  4. Enter the pattern to match group names against
  5. Choose the target type (Team, Concurrency Group, or Sub-Organization)
  6. Toggle auto-approve ON if you want matched groups to be approved automatically
  7. Click Save

Role Assignment​

Roles can be set per-user (User extension OrganizationRole) or per-group (Group extension LambdatestRoles). Roles work independently of mappings — even unmapped groups apply their roles to members immediately.

When a user is in multiple groups with different roles, the highest-priority role wins: Admin > User > Guest

GroupRole
eng-teamUser
org-adminsAdmin
Effective roleAdmin (highest wins)

Roles can be upgraded and downgraded. The effective role is always the highest across all current group memberships — removing a user from one group only downgrades their role if no other group provides it.

ScenarioWhat happens
User added to a group with Admin roleRole upgraded to Admin (if currently lower)
User removed from the Admin groupRole recomputed — drops to next highest (e.g., User) if no other group gives Admin
All groups removed, or no roles setRole defaults to User
Group's LambdatestRoles changed from Admin to GuestAll members' roles recomputed — may downgrade

One Group per Entity​

Each TestMu AI entity (team, concurrency group, or sub-org) can only be mapped from one SCIM group at a time. If you try to create a second mapping to the same entity, the request is rejected. This ensures a clear ownership model — one IDP group controls one TestMu AI entity.

Conflicts​

Teams don't have conflicts

If you're only mapping to Teams, you can skip this section entirely. Teams are additive — no conflicts possible.

Conflicts happen when a user belongs to multiple SCIM groups that compete for the same exclusive slot. When a conflict occurs, the user keeps their current assignment until an admin resolves it — nothing changes automatically.

When do conflicts happen?

When the same user is in two SCIM groups mapped to different concurrency groups. Example: Group A → "QA Pool" and Group B → "Dev Pool" — the user can only be in one.

To resolve:

  1. Go to SCIM Group Provisioning dashboard > Conflicts tab
  2. Each conflict card shows the Current group (where the user is now) and the Incoming group (the one trying to claim the user)
  3. Click Keep Current or Use Incoming
  4. TestMu AI remembers this decision — the same combination won't create a new conflict
To avoid conflicts

Prefer teams when users need to be in multiple groups — teams never create conflicts. Only use concurrency groups and sub-orgs when you need exclusive assignment.

Deleted Target​

If an admin deletes a team, concurrency group, or sub-org that has an active SCIM mapping, the mapping is flagged as target_deleted and the status changes to Pending.

Manual re-mapping required

When a target is deleted, the mapping will not auto-create a replacement — even if a matching mapping rule with auto-approve exists. This is intentional: auto-creating the same entity that was just deleted would cause a loop. An admin must manually update the mapping to point to a new (or recreated) target.

To fix a target_deleted mapping:

  1. Go to SCIM Group Provisioning dashboard
  2. Find the group with target_deleted status
  3. Click the group and select a new target entity
  4. Click Approve — members will be synced to the new target

Group API Operations​

Request: POST https://auth.lambdatest.com/api/scim/Groups

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:Group",
    "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:Group"
  ],
  "displayName": "eng-backend",
  "members": [
    { "value": "23123" },
    { "value": "23456" }
  ],
  "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:Group": {
    "LambdatestRoles": ["User"]
  }
}

Response: 201 Created

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:Group",
    "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:Group"
  ],
  "id": "50001",
  "displayName": "eng-backend",
  "members": [
    { "value": "23123", "display": "[email protected]" },
    { "value": "23456", "display": "[email protected]" }
  ],
  "urn:ietf:params:scim:schemas:extension:LambdaTest:2.0:Group": {
    "LambdatestRoles": ["User"]
  },
  "meta": {
    "resourceType": "Group",
    "created": "2025-01-15T10:30:00Z",
    "lastModified": "2025-01-15T10:30:00Z"
  }
}

What Happens When...​

Quick reference for common scenarios. Everything below is handled automatically — no action needed unless noted.

You do this in your IDPWhat happens in LambdaTestAction needed?
Rename a groupGroup name updated. Mapped team/concurrency group renamed to match. Mapping rules re-evaluated.Only if mapping reverted to Pending
Delete a groupSoft-deleted. Members safely unassigned. Roles recomputed. Conflicts auto-resolved.No
Add a member to a groupAdded to all mapped entities. Role recomputed.Only if a conflict is created
Remove a member from a groupUnassigned from mapped entities (only if no other group maps them there). Role recomputed.No
Re-push a previously deleted groupGroup restored. Members must be re-pushed. Mapping rules re-evaluated.Depends on rules
Change roles on a groupAll members' roles recomputed immediately.No

Troubleshooting​

API Errors​

ErrorCauseFix
401 UnauthorizedInvalid or expired Bearer TokenRegenerate in Organization Settings > Security
403 ForbiddenGroup Provisioning is disabledEnable the toggle in Security settings
404 Not FoundID doesn't exist or belongs to a different orgVerify via a List call
409 ConflictGroup with same displayName already existsRename or delete the existing group
400 Bad RequestUser exists in a different organizationInvite them via team invite first

Common Issues​

IssueSolution
Members not appearing in teams or sub-orgsGroup mapping is still Pending. Approve it in the dashboard or create an auto-approve mapping rule.
Members are in the SCIM group but not in the sub-orgCheck for conflicts. The user may belong to another group with a competing exclusive mapping.
User has an unexpected roleCheck all SCIM group memberships — roles follow highest-wins (Admin > User > Guest). The user may inherit Admin from another group.
User keeps getting re-added after manual removalSCIM is the source of truth. Remove the user in your IDP instead.
Group mapping reverted to PendingThe group was renamed (rules re-evaluated) or the target entity was deleted (target_deleted). If renamed, rules may auto-approve. If deleted, manual re-mapping is required.
Auto-approve didn't create my sub-organizationSub-orgs are never auto-created (billing/setup required). Create the sub-org first, then approve manually.
Can't map two SCIM groups to the same teamEach entity can only be mapped from one SCIM group. Use a single group, or merge in your IDP.

FAQ​

QuestionAnswer
Can a group be mapped to multiple targets?No. A single SCIM group can only map to one entity (team, concurrency group, or sub-org). To assign the same users to multiple entities, use separate IDP groups.
Can two SCIM groups map to the same entity?No. Each entity can only be owned by one SCIM group. This prevents conflicting membership lists.
Can I disable group provisioning without losing data?Yes. The toggle only blocks new IDP operations. Existing groups, mappings, and assignments are preserved. Toggle back ON to resume.
Can I restore a deleted group?Yes. Push a group with the same displayName from your IDP — the soft-deleted record is restored. Members need to be re-pushed.
Can roles be downgraded?Yes. Roles are recomputed across all groups. If the highest role is removed, the effective role drops to the next highest. Defaults to User if none set.
What happens to a conflict when one group is deleted?The conflict is auto-resolved in favor of the remaining group. No admin action needed.
What's the difference between Approved and Auto-Approved?Both sync members identically. Auto-Approved = mapping rule matched automatically. Approved = admin approved manually.
Do mapping rules overwrite existing mappings?No. Rules only apply when a group is first created or renamed. Existing mappings (manual or auto) are not overwritten.

That's all you need to know about SCIM Provisioning with TestMu AI. In case you have any questions please feel free to reach out to us via the 24/7 chat support or email us over [email protected].

Last updated on

Test across 3000+ combinations of browsers, real devices & OS.

Book Demo

Help and Support

Related Articles