Remove the Escalation of access request

Hi All,

We are setting up access requests for AD groups, and if the designated approver doesn’t approve the request, it is escalated to the approver’s manager. Is there a way to prevent this escalation?

We want the access request to remain with the original approver only. How can we ensure the request expires after 14 days?

Additionally, is there a way to send reminder emails to the approver?

Regards,
Ramya


API-to-set-global-reminders-and-escalation-policies-for-acces

Update the Access Request Configuration with that

 "approvalReminderAndEscalationConfig": {
        "daysUntilEscalation": null,
      .....
    }

First do a get to see the existing config :
get-access-request-config | SailPoint Developer Community

Then update the approvalReminderAndEscalationConfig object :
set-access-request-config | SailPoint Developer Community

Can anyone confirm that this actually works? Last I tried this a number of months ago and logged a support ticket about it, turns out you cannot separate the two: You HAD to have Escalations AND Reminders, you couldn’t set Escalations to 0 and keep reminders. I’m testing it now but given @maria-lima quote above:
IMPORTANT: Specifying a value of 0 for any of these escalation policy parameters will generate the following results:

I read that as I found in my testing - if I set daysTillEscalation to 0 but set values for the Reminders - the net results is it will still do nothing. I am testing this right now (again) and will know in a day if a reminder actually comes.

@srezzaki The API doesn’t let set escalation days to null (even though the GET returns it like that). So you HAVE to use 0, and if you do I think it kills everything.

Try using this body containing basic configuration of a new ISC tenant with the API call :

{
    "approvalsMustBeExternal": false,
    "autoApprovalEnabled": false,
    "reauthorizationEnabled": false,
    "requestOnBehalfOfConfig": {
        "allowRequestOnBehalfOfAnyoneByAnyone": true,
        "allowRequestOnBehalfOfEmployeeByManager": false
    },
    "approvalReminderAndEscalationConfig": {
        "daysUntilEscalation": null,
        "daysBetweenReminders": null,
        "maxReminders": null,
        "fallbackApproverRef": null
    },
    "entitlementRequestConfig": {
        "allowEntitlementRequest": true,
        "requestCommentsRequired": false,
        "deniedCommentsRequired": false,
        "grantRequestApprovalSchemes": "sourceOwner",
        "revokeRequestApprovalSchemes": null
    }
}

@srezzaki
So if I PUT this, it’s accepted:


{
    "approvalsMustBeExternal": false,
    "autoApprovalEnabled": false,
    "reauthorizationEnabled": false,
    "requestOnBehalfOfConfig": {
        "allowRequestOnBehalfOfAnyoneByAnyone": true,
        "allowRequestOnBehalfOfEmployeeByManager": false
    },
    "approvalReminderAndEscalationConfig": {
        "daysUntilEscalation": null,
        "daysBetweenReminders": null,
        "maxReminders": null,
        "fallbackApproverRef": null      
       
    },
    "entitlementRequestConfig": {
        "allowEntitlementRequest": true,
        "requestCommentsRequired": false,
        "deniedCommentsRequired": false,
        "grantRequestApprovalSchemes": null,
        "revokeRequestApprovalSchemes": null
    }
}

If I then go PUT this (adding reminders values), it gets denied with ““400.1 Bad request content””.


{
    "approvalsMustBeExternal": false,
    "autoApprovalEnabled": false,
    "reauthorizationEnabled": false,
    "requestOnBehalfOfConfig": {
        "allowRequestOnBehalfOfAnyoneByAnyone": true,
        "allowRequestOnBehalfOfEmployeeByManager": false
    },
    "approvalReminderAndEscalationConfig": {
        "daysUntilEscalation": null,
        "daysBetweenReminders": 1,
        "maxReminders": 2,
        "fallbackApproverRef": null      
       
    },
    "entitlementRequestConfig": {
        "allowEntitlementRequest": true,
        "requestCommentsRequired": false,
        "deniedCommentsRequired": false,
        "grantRequestApprovalSchemes": null,
        "revokeRequestApprovalSchemes": null
    }
}

Also for reference, it appears that using 0 for daysUntilEscalation but having values in reminders, also does not work per my previous observation. I did not receive a reminder email after 24 hours.

So…null doesn’t work, and zero doesn’t work - I think this just doesn’t work per what I suspected.

I’ve confirmed with a couple different CSMs now that Escalations and Notifications are linked as one: You cannot separate them out and have one or the other (even though it seems perfectly logical to be able to).

1 Like

@ramya_14
So here is something that might be useful to you. I found this post:

In the case he mentioned, he is taking certain actions based on other variables of the request. However, it can be used to DENY any pending requests older than a certain date too.

I am uploading a workflow JSON that you can adjust to say “Deny request after 14 days” if you want. I just tested this in Sandbox and confirmed it worked as expected. It denied the Pending requests that were beyond the age limit.

So what was suggested to me is that if you WANT to have Reminders, but DON’T want it to ever escalate to anyone: You can set the access-request-config to something like this:

And setup the below workflow to DENY requests at 15 days old. So, you should get the reminder emails, and the request gets denied by the workflow before it has a chance to get escalated.

I’m testing this right now and will know if its all good in a couple days.

CopyofDenyRequestsOlderthan90Days20250303.json (2.5 KB)

Hi Kevin,

Thanks for your response. Did that workflow work ?

Regards,
Ramya

The workflow itself, appears to be working. However, my notifications aren’t working!

This is my current Access request configuration that I set before logging a test request - and I haven’t gotten a single reminder beyond the initial notification.
grrr…Maybe I didn’t wait long enough after setting this before logging a test request or something nuts. I’ll go try one more time for fun before logging a support ticket; this should work.

"approvalReminderAndEscalationConfig": {
    "daysUntilEscalation": 5,
    "daysBetweenReminders": 1,
    "maxReminders": 2,
    "fallbackApproverRef": {
        "email": "REDACTED",
        "type": "IDENTITY",
        "id": "REDACTED",
        "name": "REDACTED"
    }

Wait I’m an idiot and misunderstood the access request config, specifically the daystillEscalation attribute.

I was doing this, and setting my workflow to DENY it after 4 days…assuming on the 5th day it would escalate.

"approvalReminderAndEscalationConfig": {
    "daysUntilEscalation": 5,
    "daysBetweenReminders": 1,
    "maxReminders": 2,
    "fallbackApproverRef": {
        "email": "REDACTED",
        "type": "IDENTITY",
        "id": "REDACTED",
        "name": "REDACTED"
    }

But I wasn’t getting any reminder emails; I’m being told what I REALLY need to do is this. The ‘daysUntilEscalation’ is actually the amount of reminders you’ll get, and maxReminders is the limit before it escalates. So in this config, I should get a reminder every day for 3 days, on the 4th day my Workflow will deny it, so it never makes it to the 5th day of reminders (and escalates).

Testing this again today.


"approvalReminderAndEscalationConfig": {
    "daysUntilEscalation": 1,
    "daysBetweenReminders": 1,
    "maxReminders": 5,
    "fallbackApproverRef": {
        "email": "REDACTED",
        "type": "IDENTITY",
        "id": "REDACTED",
        "name": "REDACTED"
    }

OK this worked in testing. So in Prod, I have set it to send a reminder every 2 days, for a max of 15 reminders (30 days total) and escalate at 99 days. The workflow is set to Deny anything older than 30 days.

Hi Kevin,
Hope you are doing good.
We are also trying the similar settings in our tenant, by deploying the workflow which will cancel the pending request greater than 30 days.

We are planning to configure below settings and please share your feedback if this will stop escalation before 30 days but sending reminders to approver every week for 3 times.

“approvalReminderAndEscalationConfig”: {
“daysUntilEscalation”: 4,
“daysBetweenReminders”: 7,
“maxReminders”: 20,
“fallbackApproverRef”: {
“type”: “IDENTITY”,
“id”: “2c917bc71e5dddddd40sssss17bc71fdb510029”,
“name”: “test suresh1”,
“email”: “test [email protected]
}

Thanks,
Suresh

If your goal is to never let the access request escalate to the next manager, then you’d want to set the ‘daysUntilEscalation’ value to something high, like 99 in my case below.

If you want a 30 day cut off and a reminder sent once a week, then you want something like this:

“approvalReminderAndEscalationConfig”: {
“daysUntilEscalation”: 99,
“daysBetweenReminders”: 7,
“maxReminders”: 4,
“fallbackApproverRef”: {

It will stop reminding after the 28th day (4th reminder, once every 7 days) And if you deploy a workflow like the JSON I had linked earlier in the thread to kill the request after 30 days, you should have no worries about escalation.

Hi Kevin,

Thank you !

Regards,
Suresh

@apparassuresh @ramya_14

Woa now - this all stopped working at some point and I’m not sure when - however, I see the API language must have changed and maybe how this works has changed too. I noticed this because I was not getting reminder emails anymore with this config:

Look at this definition on the API page:

I am 99.99% sure this “number of days to wait before the first reminder” was not there before. Also the 'If no reminders are set, days till escalation" wasn’t there before because, obviously, I have reminders set to every 2 days. So I wouldn’t ever get a reminder because of that 99 days value.

SOOOOO what I’m saying is it seems Sailpoint have changed the behavior of this config. Where it USED to be you HAD to have Escalations AND Reminders configured together (and use a workflow to kill requests to make sure it didn’t get escalated), it looks like they made it so you can use Escalations OR Reminders (which is the way it should have been from the start). So…that’s great…I just wish there was a way I would know about this changes before finding it broken.

I’m going to test these out.