> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/end-user-guide-for-selfservice/approvals/request-administration.md).

# Request administration

Oversee requests across your area — find stuck ones, reassign approvals, and keep things moving.

**Request Administration** is a wider view of requests than your own queue: it covers the requests in the area you are responsible for, whoever raised them and whoever is approving them.

Open it from **Requests → Request Administration**. It needs a delegated-administration permission, so most people won't see it.

## What it's for

Your own queue answers "what needs me?" This page answers "what is happening across my area, and what is stuck?"

Typical uses:

* **Finding requests that have stalled** — waiting on someone who is on leave, or sitting untouched for weeks.
* **Reassigning an approval** when the approver can't act.
* **Answering questions** — "what happened to the request I raised for Priya?" — without asking the person to look it up.
* **Spotting patterns** — the same access requested repeatedly may be a sign it should be birthright access instead.

## Finding what you need

Search and filter by requester, by the person the request is for, by status, by date, or by request number. The most useful filter is usually **oldest first with a waiting status** — that surfaces the stuck ones immediately.

Open any request to see its full detail and approval trail.

## Reassigning an approval

When a request is stuck on someone who cannot act — long leave, changed role, left the organization — you can move the approval to someone who can.

{% stepper %}
{% step %}
**Open the request and check the trail.**

Confirm which step is waiting, and on whom.
{% endstep %}

{% step %}
**Reassign to the right person.**

Choose someone with the authority and the knowledge to make the decision.
{% endstep %}

{% step %}
**Tell them.**

A reassigned task arrives without context. A short message explaining why it's now theirs gets it dealt with far faster.
{% endstep %}
{% endstepper %}

In the new SelfService, open the request and click **Delegate** in the page header, then choose the step and the person. The person you choose can decide the step, and the current approvers lose it. A request that nobody can act on — one whose step has no approver, or that is overdue — says so at the top of the page. **Cancel request** sits next to **Delegate**. Your reason is recorded as an administrator cancellation and sent to the requester.

{% hint style="warning" %}
Reassigning changes who is accountable for the decision, and that is recorded. Move approvals to the right person — not simply to whoever answers quickly. An approval given by someone without the knowledge to judge it is worse than a delayed one.
{% endhint %}

## Keeping the queue healthy

* **Look regularly rather than when someone complains.** A weekly pass catches problems while they're small.
* **Deal with the oldest first.** Age is the best indicator of something genuinely stuck.
* **Fix causes, not just symptoms.** If requests always stall at the same step, the approval route may need changing — that's a conversation with whoever configures the workflow.
* **Watch for repeats.** The same request from many people suggests the access should be granted automatically by job or department.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/end-user-guide-for-selfservice/approvals/request-administration.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.