It appears when the request is cancelled during Provisioning Approval Subprocess, the workflow is terminated. Only the catches step is executed afterwards to finalize the identity request.
However I want to perform other actions if the request is cancelled - I want to execute a different provisioning plan.
It appears I cannot have more than 1 catches=complete step, only the first one is executed. And I cannot transition to other steps from a catch step.
If I use the catches step to perform my custom provisioning on request cancel, then I cannot make use of any OOTB workflows like Identity Request Provision and Identity Request Finalize.
What other options do I have?
Can I break apart Provisioning Approval Subprocess? But where is the part where request cancellation is handled?
You can use after provisioning rule specifc to application if you want to do some additional steps. It is better to keep your additional logic de-coupled from the default provisioning workflows.
My workflow step isn’t specific to any application. Putting that in after-provisioning rule of all application is not feasible.
My workflow is a termination on a timer.
After approval, if the user allows it to run normally, it will wait until a specific date, then terminate the user.
But if the user cancels it, it should terminate the user right away.
So I need to be able to catch the event of user cancelling the identity request. SailPoint seems to just terminate the workflow on cancel.
I can use a catches=complete step, but then I must do everything in a single workflow step and cannot reuse any of the OOTB workflows. I can do the immediate termination with Provisioner, but I’d rather have a way to use Identity Request Provision and have it record the action in the Identity Request.