> 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.md).

# Approvals and tasks

Find the items waiting for your decision and understand what you are being asked.

If people's requests need your agreement, they arrive here. **My Tasks** — also shown as **Pending Approvals** — is your queue.

Open it from **Requests → Pending Approvals** in the sidebar, or from the **Pending Approvals** shortcut in the top bar.

## What lands in your queue

| Task type          | What you're being asked                                   |
| ------------------ | --------------------------------------------------------- |
| **Request access** | Someone wants access; do you agree?                       |
| **Revoke access**  | Someone is giving access up; confirm it should go         |
| **Review access**  | Confirm whether someone's existing access is still needed |
| **New user**       | Approve the creation of an account                        |
| **Profile change** | Approve a change to someone's details                     |

You may receive tasks because you are someone's manager, because you own the thing being requested, or because your organization routes certain approvals to your team.

## Reading the list

| Column                  | What it tells you                                |
| ----------------------- | ------------------------------------------------ |
| **Request ID**          | The reference number, in the form `REQ-12345`    |
| **Requestor Name**      | Who raised it                                    |
| **Request created for** | Who the access is for — often a different person |
| **Employee ID**         | The employee number of the person it is for      |
| **Created Date**        | When it was raised — your ageing indicator       |
| **Task type**           | Which of the kinds above it is                   |
| **Short description**   | What is being asked                              |
| **Actions**             | What you can do with it                          |

Note the difference between **Requestor Name** and **Request created for**: a manager frequently requests on behalf of a team member, so the person who asked is not the person who gets the access. When you approve, you are approving access *for* the second person.

When nothing is waiting, the page reads *"No pending approval tasks found."*

## Finding one in a long queue

A filter bar sits above the list: **Request ID**, **Requestor Name**, **Requested For**, **Employee**, **From Date**, **To Date**, **Task type**, and **Description**.

The one worth learning is **From Date** / **To Date**. Sorting by **Created Date** and looking at the oldest first is how you find the requests that have genuinely been forgotten, rather than the ones that arrived this morning.

At the bottom you can set **Rows per page** and move between pages.

## Acting on several at once

Each row has a checkbox, and the footer shows how many you have selected. This is useful when a batch of requests are obviously the same decision — a group of new starters all needing the same tool.

{% hint style="warning" %}
Selecting many rows and approving them together is exactly how access gets granted that nobody intended. Use it when the requests are genuinely identical and you have read one of them properly — not as a way to clear a backlog quickly.
{% endhint %}

## Acting on a task

Open a task to see the full request, then decide. See [Approving, rejecting, and delegating](/end-user-guide-for-selfservice/approvals/approve-reject-delegate.md).

Going away? Hand your approvals over — see [Out of office](/end-user-guide-for-selfservice/approvals/out-of-office.md).

{% hint style="info" %}
Approvals age badly. An access request that sits for a week is someone unable to do their job, and rushed approvals at the end of a backlog are where mistakes happen. A short, regular pass through this queue is easier than a long one.
{% endhint %}


---

# 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.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.