Summary: During batch AddEntitlement provisioning via Identity Refresh, the Web Services Connector reuses the requestEndPoint URL from one operation for all subsequent operations in the batch, instead of constructing a unique URL per entitlement. This causes 409 “Already Exists” errors on target systems that require unique URLs per entitlement (e.g., JumpCloud’s /usergroups/{GROUP_ID}/members endpoint).
What is the correct behavior?
When multiple AddEntitlement operations are dispatched in a single provisioning plan, the connector should dynamically replace the URL path variable for each entitlement. For example:
- Entitlement 1 →
POST /usergroups/5f07cf84b544065386e22b5d/members - Entitlement 2 →
POST /usergroups/62865991e8ab42000180ae83/members - Entitlement 3 →
POST /usergroups/6287b3a1fa71fd0001e5ac28/members
Actual behavior: All 9 requests are sent to the same URL (e.g., /usergroups/62865991e8ab42000180ae83/members), causing the first call to succeed and subsequent calls to return 409 “Already Exists” because the user is already a member of that specific group.
What product feature is this related to?
The Web Services Connector’s batch provisioning logic when handling multiple AddEntitlement AttributeRequest objects in a single ProvisioningPlan. This specifically affects APIs that require entitlement-specific URL paths (not just body parameters).
What are the steps to reproduce the issue?
- Configure a Web Services Connector source against an API that requires per-entitlement URL paths (e.g., JumpCloud:
POST /usergroups/{groupId}/members) - Define the
AddEntitlementoperation with a URL path variable like$entitlement.id$ - Assign an identity multiple entitlements (e.g., via Access Profiles in a Role)
- Trigger an Identity Refresh that provisions multiple entitlements for the same identity
- Observe that all API calls use the same group ID in the URL, regardless of the
attributeValuefield in the provisioning plan
Evidence from event logs
The AddEntitlementFailure events in the ISC event log show the mismatch:
| Field | Value |
|---|---|
attributeValue |
5f07cf84b544065386e22b5d (correct target group) |
URL in errors field |
/usergroups/62865991e8ab42000180ae83/members (wrong group — same URL for all 9 requests) |
The user IS a member of all 9 target groups in the target system (confirmed via API). The 409 errors are caused by the connector sending all requests to the same (wrong) group URL, not by the target system rejecting valid requests.
Environment
- Connector: Web Services (OOTB, no customization)
- Rules: None — no
BeforeOperationRule, noAfterOperationRule, no BeanShell addRemoveEntInSingleReq: Not set (default)- Target system: JumpCloud (REST API)
- Trigger: Identity Refresh (not manual access request)
What have we tried?
- Verified the user’s actual group memberships via JumpCloud API — all correct
- Confirmed no custom rules exist on the source
- Reviewed
addRemoveEntInSingleReqdocumentation — this parameter batches entitlements into a single JSON payload but does not fix URL path construction - Opened a support case (currently being deflected to Professional Services)
Related threads
- Multiple entitlements in the same operation (#103487)
- Combining multiple requests into one using addRemoveEntInSingleReq (#69043)
- ISC SharePoint Online Connector “struggles” with Bulk Entitlement Removal (#185547) — similar class of OOTB connector bulk operation defect, now marked
fixed
Has anyone else experienced this behavior with the Web Services Connector when the target API requires unique URLs per entitlement? Is there a connector-level configuration fix, or is a BeforeOperationRule the only workaround?
