I reviewed this post and I’m facing the similar issue:
I would like to try the request chaining option instead of using before provisioning rule option. But in the Add-Entitlement HTTP operation, I don’t see the parent endpoint option to configure request chaining. Please assist.
You don’t need to have a “parent” endpoint for it, however you can utilize the Before and After operation Rules for it.
Also if you create multiple add entitlements operations they can work in a similiar way as the create one, the only thing is that you wouldn’t have the “response” of the other endpoint.
I did use multiple same operation type endpoints as a chaining requests. Yes, we do not have parentEndpoint on the UI, but you can still define multiple similar operations. ISC takes the order into consideration and passes the response data to the next endpoint.
Here is the example how I used it for disable operation. Our requirement was to pass email attribute for disable operation, however our nativeidentity is different. We had to define nativeIdentity different than the email as it is needed in add/remove entitlement, update account operations and always populated.
Here is how we achieve it without using the rules.
Disable Account (display name: Get Single User details for Disable) → Invoked API to fetch single account aggregation which provides email information too and declared the response mapping to capture email.
Disable Account – Use the $response.email$ in the request body of actual disable account API to disable the account
This worked for us well, we used the similar method for several other integrations too. Hope this is helpful.
Thank you so much for your response. I did create 2 Add-entitlement operations but missed to map the response which caused the error. Your response helped me update it and the provisioning works like a charm now
Conclusion: Provisioning operations can be chained as well and before / after operation rules can be a last resort. I hope the connector documentation is updated to capture this clearly