Multiple entitlements in the same operation

Hi Guys,

I have a Web Services integration that, when altering a user, needs to send the entitlements the user will have in the Body. Therefore, if the user has 3 entitlements, the body will look something like this:

json

{
  "roles": [
    {
      "id": "2929292929",
      "id": "9839499433",
      "id": "3939394812"
    }
  ]
}

Each ID represents the internal ID of the entitlement in the application.
If I send only one ID, the application will delete all the others and leave only that one.

With this in mind, I created a Before Rule that summarizes the entitlements and places them in the body. However, I’m facing a difficulty where each entitlement is going to a different operation with a different plan, making it difficult for the Before Rule to analyze the access request in its entirety.

Is there a way for the access request to generate only one plan with all the entitlements to be removed/added so that the Before Rule can analyze and construct the body correctly?

This is not only in Create with Entitlement, its also in Add/Remove more than 1 entitlement.

Thanks.

Hi Lucas,

There is a connector level attribute (addRemoveEntInSingleReq) you can set to include all instances of a single entitlement type in one provisioning plan. Here’s the documentation on it! - Configuring Requests for Multiple Entitlements

Let me know if that solves your use case.

Thanks!

Liam

1 Like

Hi Liam!

It’s already set. I don’t know why its not working :confused:

My connector attributes:

"connectorAttributes": {
        "healthCheckTimeout": 30,
        "clientCertificate": null,
        "deltaAggregationEnabled": false,
        "accesstoken": "2222",
        "throwProvBeforeRuleException": true,
        "checkDeletedDisabled": false,
        "connectionType": "direct",
        "client_id": null,
        "numPartitionThreads": null,
        "password": null,
        "expiredPasswordErrorMsg": null,
        "addRemoveEntInSingleReq": true,
        "client_secret": null,
        "clientKeySpec": null,
        "saml_headers_to_exclude": null,
        "sourceConnected": true,
        "createAccountWithEntReq": true,
        "saml_headers": null,
        "disableCookies": false,
        "private_key": null,
        "version": "v2",
        "labels": [
            "standard"
        ],
        "slpt-source-diagnostics": "{\"connector\":\"web-services-angularsc\",\"status\":\"SOURCE_STATE_HEALTHY\",\"healthy\":true,\"healthcheckDisabled\":false,\"healthcheckCount\":69,\"lastHealthcheck\":1741604913921,\"statusChanged\":1741374924456}",
        "formPath": null,
        "objectNotFoundErrorMsg": null,
        "refresh_token": null,
        "cloudCacheUpdate": 1741382348008,
        "saml_request_body": null,
        "authenticationMethod": "OAuthLogin",
        "httpCookieSpecsStandard": "true",
        "authenticationFailedErrorMsg": null,
        "connectorName": "Web Services",
        "enableStatus": "status=accepted",
        "since": "2025-03-07T19:15:24.456Z",
        "status": "SOURCE_STATE_HEALTHY",
        "supportsDeltaAgg": "true",
        "lastAggregationDate_group": "2025-02-25T19:43:03Z",
        "resourceOwnerUsername": null,
        "oAuthJwtHeader": null,
        "enableHasMore": false,
        "isGetObjectRequiredForPTA": true,
        "timeoutInSeconds": "60",
        "genericWebServiceBaseUrl": "xxxx",
        "resourceOwnerPassword": null
}

Hi Lucas,

From your pictures I believe it is but just want to confirm - are the entitlements you are trying to bundle into one provisioning plan of the same entitlement type?

Also after some more digging, I believe these entitlements would need to be a part of the same role or access profile to be grouped together. Found this solution on the forums by Colin that describes this behavior - Get multiple entitlements in access request within the same plan - #2 by colin_mckibben

Found some other solutions where people have called back to the ISC APIs in a before rule to see what other access was requested by the user and then add those to the prov plan. This solution is much more involved though. Will link it here for your reference - Combine multiple entitlement types into one provisioning request

Thanks!

Liam

1 Like

Hi Liam,

Thank you for your efforts. Both solutions work well for me. In this case, we are implementing the first solution, but it’s good to know that the second option is available.

Best regards, Lucas

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.