Failure in the child workflow do not affect the main workflow, hence you might see it ending successfully. You didn’t mention the step used in the child workflow which causes the error. Some of the Idn API’s require OAuth2.0 authentication and do not work with PAT tokens I faced a similar error when made a http request step for an Idn API. If it is an API call that you are making, please check the permissions of what kind of authentication is expected. If not, provide more details about the failure step.
Thanks for responding Uday,
We are using a global client ID an Secret, and we are also using the Access Request Dynamic Approver trigger, to check if we have any SoD conflicts in relation to the access profiles, if there is any conflict related to the SoD policy created, add an approval step, and that is what is not happening, this step of adding a new approval group.
Thanks for the details of the workflow. It is still not clear to me what is the request URL used in the http requests made in child workflows. Can you provide information about that?
There are 4 http requests: With the objective of listing the requests, validating if any of them occurs a SoD violation, if this occurs, a new approval is added, so speaking of the 4 http requests in the order they appear in the workflow
Third http request to add the new approval, if there is violation SoD adds a new approval “$.loop.context._metadata.callbackURL” and request body"{“output”:{“id”:“xxxxID_group”,“name”: “Group_Name “,“type”:“GOVERNANCE_GROUP”},“secret”:”{{$.loop.context._metadata.secret}}”}"
And the fourth http request if there is no SoD violation sends “$.trigger._metadata.callbackURL” and request body “{“output”:{“id”:”“,“name”:”“,“type”:”" },“secret”:“{{$.trigger._metadata.secret}}”}"
This is the data from the 4 http requests shown in the workflow.
However, a new approval should be generated so that the approver can validate the real need of the requester and to grant access or not depending on his position.
That is almost certainly your issue. Please create a PAT instead of a global client credentials. Almost every one of our APIs require some user context, which is provided with a PAT. Client credentials only works for a couple of endpoints.
Hello, thank you for providing the workflow. Could you please clarify if this workflow is designed for obtaining additional approval when a SoD violation is detected? Additionally, if the additional approver grants approval, will the user be granted the entitlements that were in violation of the SoD policy? Lastly, would it be possible to obtain more detailed information about the workflow?
We received help from Sailpoint to recreate the workflow and it is now correctly generating the new approval. And the instruction was to actually use a PAT for the process.
Thank you very much for everyone’s help here, you are excellent.
If it works, please come back to this topic and mark the reply as the solution so future users know what the solution is.