There are some “challenges” in our environment that I would like to solve, and on the face of it, adaptive approval workflows might seem to be the answer; however, it is not a feature that we currently own. So before I make a push to management to get the money, I need some questions resolved. Unless someone can point me to a demo of the feature.
My primary challenge is that, depending on the item being requested, I have certain prerequisite conditions that need to be met. If the requester does not meet these conditions, or the account selected is not suitable for the entitlement, I want to reject the request out of hand. So far, this is not a problem. I can do that with a workflow. The problem I run into is that if the user DOES meet the criteria, I do not appear to have a way to tell ISC to continue with the request’s normal approval process. If I use the access request submitted trigger, then it appears that my workflow is responsible for handling the approval or rejection. workflow must have at least one action 'sp:access-request-approval' when trigger is 'idn:access-request-trigger'
What I want is a way to make a first pass over the request and then send it on its merry way, following the approval flow defined in the entitlement. Will adaptive workflows allow that?
I had the same issue while configuring a workflow that it needs approval policy first else it will generate this validation error. It was fixed only when I added approval policy, so my view here, that before doing complex checks and process, the request should pass approval to handle cases where provisioning starts even when an user raise request as part of human error.
Also I would recommend if you raise a case for sailpoint to provide your solution refined to your design.
Think this might be what you’re after to do the first pass of the programmatic approval, from the event subscription side of things:
“This trigger intercepts newly submitted access requests and allows the subscribing service to perform a preliminary approval/denial before the access request moves to the next approver in the chain.”
This contradicts with OP’s statement of “following the approval flow defined in the entitlement.” Unless there’s a way to specify a workflow AND the approval flow simultaneously.
@David_Norris , Is this just a lack of understanding? When I read the documentation in your post, it says,
“This trigger intercepts newly submitted access requests and allows the subscribing service to perform a preliminary approval/denial before the access request moves to the next approver in the chain.“
Does that mean if my workflow ends up at an “approve access request” action, then when the workflow stops (success), the request will continue on the approval flow as if there was never a workflow? Meaning that if the access request configuration for the item stipulated a manager’s approval, it would then go to that manager next?
Conversely, if my workflow ended up at a "deny access request” action, then the request would not move forward and would be canceled?
@David_Norris on the Entitlement you have to choose an Approval Type. Either Reviewer, which is the traditional way of defining the approval. Or you can choose Workflow. You can’t do both.
If you choose Workflow, then you can use the Approval Policy action which acts very similar to the Reviewer option. But it has some additional features like doing Parallel approvals instead of Serial.