Hi All,
First of all, i am still a beginner with ISC so please explain to me if i am missing something here even the obvious stuff.
It looks like the API call that is being performed in ‘Get Identity‘ action fails.
This action being a black box i dont think we can play around with it too much? Did anyone else encounter this issue in the past and how was it resolved?
Also, it fails on all the workflows that use that action.
Thanks in advance,
Alex
Hi @alexc ,
welcome SailPoint Developer Community !
can you please double check and make sure the identity id present in tenant that you are passing in the HTTP Request - Get identity Details step
thanks
avi.
Hey Avi,
Yes, i forgot to mention that. The identity id is correct. When i make the same call from my laptop it responds with a 200
What i notice is that in my /v3 collection there are no identities option but using beta gives a correct response.
Could you please check to make sure there’s authorization header or make sure the JWT token isn’t expired?
First thing, if you enabled the Workflow first time in your tenant and it take up to 2 hours for it to be fully functional and you may expect an error when building it.
Next, try to recreate the Workflow and run it, sometimes it resolves the issue. I understand it is not the valid solution, but I did experience it in the past.
Since HTTP 401 is unauthorized, please check whether the owner identity of the Workflow exists and active with required user level permission in your tenant.
If above are not working, I would create a support ticket.
Hi Noor,
Not sure how i can check that in the context of a workflow? To me this seems like ISC is making internal API call to itself to get that identity information?
Hi @alexc a few things to check.
$.trigger.identity.idYou are correct: /identities is indeed experimental, meaning it’s available in Beta, and in v2024 and v2025 by setting the ‘X-SailPoint-Experimental’ header to ‘true’.
Honestly, that error message is super surprising, and indicates exactly what you are saying: that this black box is calling /v3/identities, which supposedly doesn’t exist, but instead of getting a 404 Not Found error or a java error, you are, as @suresh4iam said, getting the 401 Unauthorized, which implies that the endpoint exists, but that the backend service making the call is using bad credentials. I know you can get a 404, because on an earlier execution of a workflow I recently developed, I did. What’s most interesting about this is that it is also calling the “nonexistent” /v3/identities endpoint:
What does the Execution JSON look like? Specifically, the failure? (There are 3 “steps” for the final Step in the Builder view: ActiviityTaskScheduled ActivityTaskStarted, ActivityTaskFailed. This will be followed by a WorkflowExecutionFailed Step. The relevant config is seen in scheduling, and the results in the failure steps:
dont worry about the API version when using an available action from workflows. Workflow action might be using different API gateway which are not available for outside usage. I would say just download this workflow and reupload it and give it a shot.
Change the owner of the workflow to an active identity that has admin rights (i.e. yourself or a purpose built “service” identity)
@alexc
This happened in one of our projects as well.
The root cause is, the person who is owner of this workflow, must have lost his Admin access OR may be entirely removed from the tenant.
Solution is simple,
Change the workflow owner..
If that does NOT work, then create a duplicate workflow using the duplicate symbol, and assign another ADmin as owner of the workflow and discard the old workflow..
Note: if your workflow steps are using PATs, make sure you update them in the relevant steps.
Hope this helps,
Thank you,
Vaibhav
