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.