We are trying to implement “Access Request Submitt” IdentityNow event triggers to approve/reject the access request.
Our requirement is not to approve/reject all requests, some of them just need to be wait for 48/72 hours before they can be approved or rejected.
can anyone please suggest if this is possible using event triggers or what is the best possible solution to achieve this.
As far as I know, there isn’t a way to insert a waiting period into the approval process. You could set the approver to be a controlled entity where the request can wait. Then run a script to inspect all of the open approvals on that entity and if the requisite number of hours has passed, reassign it to a more appropriate approver for review and approval.
Note: I haven’t fleshed out all of the details of this potential solution but I think it should be doable if it is a viable option for you.
I would take a look at the access request pre-approval trigger, configured with dispatch mode = ASYNC - and see if you can set the ‘responseDeadline’ for the subscription to such a long period.
This would mean you could inject that intermediary ‘approver’ to be a system approver that would sit on an automated ‘approval’ for the time period required, then will approve it and have it go to the next real approver for completion.
Thanks for your quick response.
If I go with suggested approach , I see following challenges:
- If we re-assign the request to another approver , wont it trigger the event again ?
- How to re-assign request to another approval through event triggers as it support only approve/reject in response
also, how can we pass request approver information in event triggers input? currently, I can see it gives accessRequestId; however, if I use V3 API’s to read approval information that does not include accessRequestId so don’t see any field to validate
My suggestion was a possible alternative to using event triggers. I just helped another customer that couldn’t use a trigger to solve a somewhat similar problem with an external script running on a utility server, so the concept is front-of-mind.
After a quick read through of the documentation @adam_creaney provided, I think his suggestion is a better choice. You may have to experiment with the value of the
responseDeadline to make sure it is flexible enough to meet your needs, but that should be pretty straight forward.