> 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/approve-reject-delegate.md).

# Approving, rejecting, and delegating

Make a decision on a task — approve it, reject it, or pass it to someone better placed.

Open a task from your queue to see everything about the request before you decide.

## What you see

| Section                   | What it holds                                               |
| ------------------------- | ----------------------------------------------------------- |
| **Request Information**   | What is being asked, for whom, and by whom                  |
| **Review current access** | What the person already has — the context for your decision |
| **Approval Log**          | Who has already decided, what they said, and when           |
| **Comment**               | Where you add your reasoning                                |

**Review current access** is the part worth using. The question is rarely "is this a reasonable thing to want?" but "does this person, with what they already hold, need this too?" — and that you can only answer by looking.

## Your three options

### Approve

Choose **Approve** to agree.

If you are the last approver, the access is granted and provisioning begins. If others come after you, it moves to them.

Add a comment where the reason isn't obvious — the next approver and any future auditor will read it.

### Reject

Choose **Reject** to decline.

The request stops and the requester is notified. **Say why.** A rejection without a reason produces an identical request tomorrow; a rejection saying "use the shared team account instead" resolves it permanently.

The page asks you to *"Enter a reason for your decision"*, and if you leave the comment empty you are told *"A comment is required."*

### Delegate

Choose **Delegate** to pass the decision to someone better placed, using **Delegate to** to pick them.

Use it when the request needs knowledge you don't have — a system you don't own, a person you don't manage — or when you'll be away.

Delegating is not the same as approving: you are handing over the decision, not making it.

## In the new SelfService

The new SelfService shows a task on a single page instead of three tabs. Everything you need to decide is on that page, and you make your decision there too.

### What the page holds

| Part of the page            | What it tells you                                                                                                                             |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Header**                  | The request number, who submitted it and when, and its status: **In progress**, **Approved**, **Rejected**, **Cancelled**, or **Expired**     |
| **Summary**                 | Who the request is for, who asked, and where it stands — for example *"You're deciding step 2 of 3"* or *"Waiting on Alex Kim · step 2 of 3"* |
| **What is being requested** | The access, account, or change being asked for. A change to someone's profile shows each field's current value next to the proposed one       |
| **Impact**                  | Shown only when it matters — for example, when the requested access conflicts with access the person already holds                            |
| **Approval path**           | One timeline of every step: who decided it, what they said, and every comment and attachment on the request                                   |
| **Decision bar**            | Fixed at the bottom of the page while it is your turn, with **Delegate**, **Reject**, and **Approve**                                         |

When a request has already finished, the page says so at the top — for example *"Approved on 3 October · final decision by Alex Kim"* — and there is no decision bar. If you follow an old email link to a step that has since moved on, the page tells you so and shows the request as it stands now.

### Choosing which items to approve

When a request covers several items, each one has its own choice, so you can approve part of a request:

| Request                                       | Choice on each item      |
| --------------------------------------------- | ------------------------ |
| Access, or a new account with initial access  | **Grant** or **Exclude** |
| A change to someone's profile                 | **Apply** or **Skip**    |
| A review of access after a change of position | **Keep** or **Revoke**   |

A button above the list sets every item at once — for example **Include all** or **Exclude all**. On a long list, use the search box to find an item.

The left side of the decision bar keeps count, for example *"Granting 3 of 4 · 1 excluded"*. If you exclude every item, you can't approve: reject the request instead. On a position-change review, **Reject** becomes **Revoke all**.

### Making the decision

{% stepper %}
{% step %}
Read the request. If its items have choices, set each one.
{% endstep %}

{% step %}
Click **Approve** or **Reject** in the decision bar.
{% endstep %}

{% step %}
Enter a comment. It is optional when you approve and required when you reject.
{% endstep %}

{% step %}
Confirm. The dialog tells you what happens next: who decides the following step, or that access is granted because yours is the last step.
{% endstep %}
{% endstepper %}

Your organization may ask you to confirm your identity before a decision is saved. If you cancel that check, nothing is submitted, and your comment is kept.

To pass the step to someone else, click **Delegate** and choose the person. They decide the step instead of you.

### Steps shared with other approvers

Some steps go to a group of approvers. The page then asks you to **Claim** the step before you decide it. Once you claim it, the others sharing it can no longer decide it. **Unclaim** gives it back to the group.

### Comments and attachments

You can comment on a request at any time, including while it is waiting on someone else. Choose whether the comment is about the whole request or one item, attach files if they help, and choose whether to email the approvers and the requester. Your comment appears in the approval path.

### More actions

The **⋯** button in the header holds **Copy link**, which copies a link to the request so you can share it, and **Reference IDs**, which lists the numbers the help desk may ask for. If you are allowed to cancel the request, **Cancel request** is there too, and asks you to confirm.

## Deciding well

Before you approve, three questions cover almost every case:

1. **Does the job need it?** Not "would it be handy" — would the work fail without it?
2. **Do they already have enough?** Check **Review current access**. People often request something they can already reach another way.
3. **Does it combine badly?** Some pairs of permissions shouldn't sit with one person — raising a payment and approving it, for example. If a warning appears about conflicting access, take it seriously and ask before overriding.

And a fourth worth remembering: **should it expire?** If the need is temporary, a time-limited grant is safer than a permanent one.

{% hint style="warning" %}
Your decision is recorded permanently against your name. Approving in bulk without reading is how people end up explaining, months later, why someone had access they shouldn't have. If you don't have the context to decide, delegate instead of guessing.
{% endhint %}

## If you're going to be away

Set up an [out-of-office delegate](/end-user-guide-for-selfservice/approvals/out-of-office.md) before you go. Requests don't pause while you're on leave — they simply queue, and your team is blocked behind them.


---

# 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/approve-reject-delegate.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.