currently we are using 8.3p3 and how to rectify this issue We’re using the SCIM connector and have enabled relaxConfiguration=true, skipGrpUpdate=true, and updateGroupViaUsers=true. Despite these settings, group memberships are not being included in the initial user creation payload. Instead, the connector is making a separate call to /Groups to add members, which results in a 403 error. Is there a way to ensure that group data is merged directly into the user payload during creation, rather than triggering a separate group update call?
This is expected behavior with the SCIM connector – even with relaxConfiguration=true, skipGrpUpdate=true, and updateGroupViaUsers=true, the connector usually sends the group memberships as a separate PATCH/POST call to /Groups after the user is created.
Those flags only control whether group updates are skipped or attempted separately — they don’t merge the group list into the initial /Users payload. By design, IdentityIQ first creates the user object and then performs group assignments in a follow-up step. That’s why you see the extra call to /Groups and the resulting 403.
If your SCIM target doesn’t allow updating group membership that way, you’ve got two main options:
-
Adjust the target API – allow group membership changes via the
/Groupsendpoint (most SCIM services support PATCH or PUT for this). -
Customize the provisioning plan or connector rule – intercept the provisioning plan in a Before Provisioning or Before Operation rule, and manually merge the group membership data into the user creation payload before the
/Userscall is sent.
There’s no out-of-the-box configuration flag to make IIQ send group memberships inline with user creation. It needs a small connector or rule customization if your target requires that behavior.
if this post helps, please mark this as solution, as it will help others, if they have same requirements.
HI @Sravs_007 ,
check by Setting the group attribute as ManagedAttribute and remove Entitlement.
Thank you @dheerajk27 it worked