here is the sample curl command to request an access token
curl -X POST -d “client_id=7da65942-09aa-4ac5-XXXXXXXXX&client_secret=3654be3d603a0aa445f300d5c1ccc5138dc40XXXXXXXXXXXXXXXX&grant_type=client_credentials” https://{tenant}.api.identitynow.com/oauth/token
This right here is the real problem, not the fact that we don’t have a built in Trigger action in workflows for this. If this isn’t fixed this will always be an issue. I’ve submitted an idea here https://ideas.sailpoint.com/ideas/GOV-I-3395 explaining my reasoning. But essentially without a “Fire and Forget” version of this trigger this whole guide doesn’t even really do much for us and I imagine many others who want to use this Trigger.
It is entirely unreasonable to expect us to handle ALL of our use cases for this trigger in a SINGLE workflow with a million if statements at the beginning. Not only would that be impossible and a nightmare to even try to upkeep, it’s just poor implementation practice for this kind of thing.
I too struggle with the limitation of one subscription per “request response” type trigger. I haven’t delved into this with the product team to understand why the limit is one, but that is what we the users have to work with today. I suppose part of the challenge of allowing multiple subscriptions is how to deal with multiple subscribers that may respond back to the service with a decision on a particular access request. It could be as simple as first come, first serve, but I don’t know enough about the implementation to know if there are edge cases to be concerned about. Regardless, this just pushes the complexity onto the user implementation, which isn’t ideal. As you stated, the current way to handle this is to have a primary workflow with several comparison operators to determine how to handle each access request. This primary workflow could invoke child workflows to do the actual processing so that there is not a mega workflow doing it all.
It is worth noting that the request response triggers are unique in that they actually interrupt the approval chain while waiting for a response, whereas a fire and forget would not interrupt the approval chain. This is valuable because it allows an automation to preemptively deny a request before it reaches a human approver, reducing the amount of approvals a human might have to deal with. A fire and forget version of this trigger would still allow you to cancel the access request in your automation, but the approval process would still be initiated and at least one human will have received a notification to approve/deny the request.
Would your concerns be reduced if the request response triggers could accept 50 subscriptions like the fire and forget triggers?
Honestly no my concerns wouldn’t be reduced by that because then we have a whole new set of concerns related to what you said yourself above about multiple subscribers that may respond back to the service with a decision on a particular access request and all the other issues that come with multiple subscriptions to a single event that is expecting a response. I just don’t want it to need a response. Give me both options. Especially if our goal is to do something like dynamically assign an approver (we have a lot of use cases for this).
I still believe a Fire and Forget version of the trigger is a much better idea. I’ve replied to a response in my idea posted above saying similar but I don’t really see an issue with the request hitting the human approver before the automation rejects it. It’s a single annoying notification yeah but the problems it solves massively outweigh that. There’s also not really a concern of the approver approving it before the automation because I’d be impressed if someone could respond to the approval that fast intentionally, let alone with everything else they likely have going on. We certainly do not have an issue of users approving things too fast.
Either way my take is always going to be that we should have more options and this provides us that.
Is it possible to filter the event trigger on requests that have passed 1st approver (if we have multiple stages of approvals)?
Else, could it be possible to have 1 approver stage, and in the workflow dynamically add a 2nd approver to the access request for identities that are, for example, in a specific department? I have not found any APIs where I can PATCH pending access requests however…
The Access Request Decision event trigger only fires when all approvers have finished, so there really isn’t a way to be notified of each approval stage.
The Access Request Dynamic Approver is how you can accomplish this use case. This trigger allows you to add a single approver to an access request based on any arbitrary criteria you have. If you need additional approvers, you can always send forms from workflows to any number of additional approvers. The forms will sidestep the built-in approval chain, but it will allow you to have more dynamic approval processes.
Thank you the “Access Request Dynamic Approver” might just work for me, will give it a try!
According to the docs, if no identity or group should be added to a particular access request, then the subscribing service responds with the following object:
{
"id": "",
"name": "",
"type": ""
}