ISC access request config unexpected behavior turning off OoTB reminder+escalation

Feedback Bugs
, ,
1

Hi all, :slight_smile:

Previously we used this out of the box functionality from SailPoint: API to set global reminders and escalation policies for access request approvals - Compass. (Note that this documentation mentioned is outdated as it is still pointing to /v2/org.)

However, we are in the process of turning off this functionality for the following critical issues we experience with this functionality

  1. The send reminders are not mentioning that these are reminders, or which reminder it is. It just sends the original mail again.
  2. The reminders don’t mention the reassignment history.
  3. We can’t properly choose the escalation process. It will first escalate to the approver’s manager, then to their manager. If the approver was already a manager, this means that the recipients third level manager will get this request, which confuses and irritates several high-level managers. Only when the third level manager is not responding will the request be send to a fallback approver. We want to automatically reject access requests after a final reminder with a timeout message instead of escalating to any manager. The out of the box functionality can not do this.

Therefore we decided to stop using this out of the box functionality and migrating to a self-build process. For this, we are testing the process to turn this out of the box functionality off. We did this in our sandbox tenant by changing the approvalReminderAndEscalationConfig attribute with the API PUT /v2024/access-request-config:

"approvalReminderAndEscalationConfig": {
    "daysUntilEscalation": null,
    "daysBetweenReminders": null,
    "maxReminders": null,
    "fallbackApproverRef": null
  }

However, after changing this, I still notice I am getting the reminders from this functionality for the pending access request approvals.

This surprised me. Does this mean that each time an access request approval is created (or even worse, when the access request itself is created), it takes the functionality defined at that point to determine when to send reminders and escalations? Meaning we have to reject all pending access requests if we truly want this functionality to stop getting applied? Or is there a different endpoint we have to go to, to turn off this functionality?

Kind regards,
Angelo

2

That is probably the case. That’s how it worked in IIQ. A pending workflow case would store all of the reminder information based on configuration in the workflow definition. It would not reference a global configuration as you are expecting here.

2 Likes
3

It does create a separate workflow instance for each request , you can’t repro fit the configuration to old running instance.

1 Like
4

Thank you for this insight @patrickboston and @vishal_kejriwal1!

This sentence in the ISC documentation was what made me wonder if it works the same as IIQ.

This would have meant that reminders and escalations are separate workflows working on top of the access request workflows itself, and that the access request workflow itself only has logic to stay pending until it gets fed information/instruction from an external action (like approve; revoke; reassign; cancel by requester; cancel as other governance group member approved; escalate in the way mentioned by the 12 am UTC task, where the task is actually taking into account the latest changes)

But regardless of what the behavior is in IIQ, it seems weird to me that we can’t tell ISC “Stop sending reminders and stop escalating access requests to managers”, without ISC saying “Yes, will do, but I will still send a reminder in a couple days for these access requests and I will still escalate them in a couple days more, and there is nothing you can do about it, unless you kill the access requests before I can do so”.

If we actually want escalation to a manager, and we change the manager of the approver before it escalates, we also want ISC to escalate to the new manager don’t we? Or if we update the email template, we also want ISC to send the updated email right, and not still send the old email template simply because the access request was made before we updated the email template? I think that reminder and escalation actions should be applied immediately from the moment we change it, give or take a few minutes, just as it does to the two examples above.