It points to Standard Collection Parameters, and in there it mentions the following filter option: created gt 2018-12-18T23:05:55Z
I tried this in the workflow, but it gives an error.
This is preventing us to get all pending access requests that was created within a given interval, to perform actions on them. As a consequence we would now need to iterate over ALL pending access requests in our workflow, to check if the created value is within the desired interval, which takes a lot more computation within SailPoint.
Please fix this behavior such that we can use it as documented.
Thanks for your patience, Angelo. I spoke with a developer and we’ll be updating the docs to reflect the correct behavior (SAASDOCS-8315). In the meantime, you can use the syntax in the Standard Collection Parameters doc, but filter your requests using the fields in Pending Access Request Approvals List. Thank you for helping improve the docs!
Awesome, thank you! Clever way of documenting such that it does not need an update when the created filter will be supported. Only the API documentation would need the update then
I am trying out similar thing , getting all the pending request and then iterating over each request compare the date and then take action seems like unnecessary wastage of resources .
Since you can’t filter on creation date being greater and/or less than some given date(s), the best we could do is sort on created (or -created depending on use case) using the HTTP action, and iterate over them in blocks. You can then evaluate the created value of the last object of the page to determine if you need any more pages. Note that more than 250 objects might exists depending on customer organization size.
Thank you @angelo_mekenkamp , I am just curious that why you didn’t take the route of fallback approval , an request which is in fallback approval queue need to be rejected as part of expiry .
With this approach you don’t have to compare time and also don’t have to compare each and every pending request .
This forum topic is for general management of pending approvals based on created date. Even if you use a fallback approver, this would only be relevant for “expired” access requests.
But as a matter of fact my challenges also involved that part, of which you can find my post attached below, where I explain why we created our custom reminder and escalation flow, which is why we needed to be able to detect “expired” access requests to reject them automatically ourselves. SailPoint only uses the fallback approver after escalating to two managers first, which we didn’t want.