# In Discovery: Access Request Administration

**URL:** <https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402>\
**Category:** In Discovery\
**Tags:** access-requests, identity-security-cloud, in-discovery-closed\
**Created:** [January 17, 2024, 5:58pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402 "2024-01-17T17:58:26Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![aaron\_andrew](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/aaron_andrew/32/17937_2.png) [@aaron\_andrew](https://developer.sailpoint.com/discuss/u/aaron_andrew)\
**Post date:** [January 17, 2024, 5:58pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/1 "2024-01-17T17:58:27Z")

</div>

# Business Problem

The efficient movement of work through IDN is critical for customer success. The configuration of access request approval routing, the availability of people assigned to the work, and organizational change can lead to approvals sitting in unresolved states for long periods of time - and sometimes indefinitely. Compounding the issue is the lack of administrative visibility to this work with meaningful meta-information presented side-by-side with powerful controls over the work. Today, when needing to hunt down and change the status of several pieces of work, administrators are having to do this through Search or directly through APIs and are commonly doing so one request at a time.

This means access requests sit for extended periods of time - which leads to stale or incorrect identities and a loss of productivity (especially in the case of Access Requests and Provisioning Task reassignment).

## Sound Familiar?

If this is a problem that impacts your organization, use our [Ideas Portal](https://ideas.sailpoint.com/) to cast your vote for this Idea. Here you can view currently submitted ideas, add comments for your specific use cases around this problem, and vote!.  
**Idea** : [Access Request Administration / Access Request Tracking](https://ideas.sailpoint.com/ideas/GOV-I-850#_gl=1*2vlm43*_gcl_au*NjQ5MDcwMzg4LjE3MDI1NzEzNDI.)

---

<div class="post-metadata">

**Author:** ![sharvari](https://avatars.discourse-cdn.com/v4/letter/s/3be4f8/32.png) [@sharvari](https://developer.sailpoint.com/discuss/u/sharvari)\
**Post date:** [January 25, 2024, 2:10am UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/2 "2024-01-25T02:10:11Z")

</div>

Hi Andrew,

Curious to know, will the new functionality allow Org Admins to search for or view all the access requests in system including open/active, pending, completed? Will they be able to reassign / escalate it or just close it out?

---

<div class="post-metadata">

**Author:** ![angelo\_mekenkamp](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/angelo_mekenkamp/32/3386_2.png) [@angelo\_mekenkamp](https://developer.sailpoint.com/discuss/u/angelo_mekenkamp)\
**Post date:** [March 18, 2024, 4:48pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/3 "2024-03-18T16:48:47Z")

</div>

Thank you for the conversation Aaron!

Kind regards,  
Angelo

---

<div class="post-metadata">

**Author:** ![ajmerasunny1](https://avatars.discourse-cdn.com/v4/letter/a/3be4f8/32.png) [@ajmerasunny1](https://developer.sailpoint.com/discuss/u/ajmerasunny1)\
**Post date:** [March 18, 2024, 5:47pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/4 "2024-03-18T17:47:54Z")

</div>

Would love to have an options like

1. Configure reminders/escalation granularly instead of at global level, being able to include additional recipients in reminder/escalation email or dynamically provide fallback users.
2. Being able to prevent users from making duplicate request

---

<div class="post-metadata">

**Author:** ![aaron\_andrew](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/aaron_andrew/32/17937_2.png) [@aaron\_andrew](https://developer.sailpoint.com/discuss/u/aaron_andrew)\
**Post date:** [March 18, 2024, 5:56pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/5 "2024-03-18T17:56:30Z")

</div>

Hi Sharvari -

When we tackle this, we’ll definitely include all access requests across the tenant (not just one status) and we’ll allow the ability to filter on those statuses. Org admins will be able to reassign, overwrite approval, cancel, or remind pending approvers.

Currently, this project is (temporarily) on hold.

---

<div class="post-metadata">

**Author:** ![aaron\_andrew](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/aaron_andrew/32/17937_2.png) [@aaron\_andrew](https://developer.sailpoint.com/discuss/u/aaron_andrew)\
**Post date:** [March 18, 2024, 5:58pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/6 "2024-03-18T17:58:38Z")

</div>

Sunny - the ability to configure the global tenant settings under `sailpoint.api.identitynow.com/v3/access-request-config` is something we want to do long term, but it will not be a part of this effort most likely. In addition, preventing users from duplicates is likely out of scope here. I’d recommend looking for similar ideas in the idea portal.

Our focus here is exposing pending and completed access requests and allowing action on pending access requests for administrators, which has to be done via API only today.

---

<div class="post-metadata">

**Author:** ![Bakhari](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/bakhari/32/29973_2.png) [@Bakhari](https://developer.sailpoint.com/discuss/u/Bakhari)\
**Post date:** [May 10, 2024, 8:06pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/7 "2024-05-10T20:06:50Z")

</div>

Only commenting on this so that I stay abreast of where this is at, since Access Request Administration is a big pain point for my clients. 😅

---

<div class="post-metadata">

**Author:** ![kdossen](https://avatars.discourse-cdn.com/v4/letter/k/22d042/32.png) [@kdossen](https://developer.sailpoint.com/discuss/u/kdossen)\
**Post date:** [May 24, 2024, 6:36pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/8 "2024-05-24T18:36:37Z")

</div>

Same, would love for this to stay active. I get asked constantly about where a request is sitting (even if the person can check their own account.)

---

<div class="post-metadata">

**Author:** ![kbeckwith](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/kbeckwith/32/3347_2.png) [@kbeckwith](https://developer.sailpoint.com/discuss/u/kbeckwith)\
**Post date:** [August 30, 2024, 6:51pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/9 "2024-08-30T18:51:26Z")

</div>

I would love this not to be an org admin task. So have a way for a helpdesk team to read but not reassign or approve.

---

<div class="post-metadata">

**Author:** ![salam1](https://avatars.discourse-cdn.com/v4/letter/s/3d9bf3/32.png) [@salam1](https://developer.sailpoint.com/discuss/u/salam1)\
**Post date:** [May 30, 2025, 5:01pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/10 "2025-05-30T17:01:59Z")

</div>

Yes. ability to read!

---

<div class="post-metadata">

**Author:** ![aaron\_andrew](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/aaron_andrew/32/17937_2.png) [@aaron\_andrew](https://developer.sailpoint.com/discuss/u/aaron_andrew)\
**Post date:** [June 17, 2025, 2:45pm UTC](https://developer.sailpoint.com/discuss/t/in-discovery-access-request-administration/24402/11 "2025-06-17T14:45:30Z")

</div>

> [@kbeckwith](#):
>
> I would love this not to be an org admin task. So have a way for a helpdesk team to read but not reassign or approve.

Shajedul - We’ve since released this and it includes a user level for that specific use case.
