> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/my-delegations.md).

# Delegate access request approvals

Add delegates who can approve access requests alongside you, on a schedule or indefinitely, and manage delegations on behalf of other users.

Add one or more delegates who can approve access requests alongside you, so requests keep moving while you are unavailable.

Delegation is additive. A delegate is added to the approver set for your requests; you are not removed and you keep the ability to approve. Either you or a delegate can act on a request.

## Add a delegation

1. In Access Hub, go to **Catalog** > **My Delegations**.
2. Select **Add delegation**.
3. In **Delegates**, select one or more users. Each delegate must already have a Veza user account.
4. (Optional) Add a **Note** describing why the delegation exists, such as planned leave.
5. (Optional) Set a schedule. See [Schedule a delegation](#schedule-a-delegation).
6. Select **Add delegation**.

The delegation appears in the **Delegations** table, which lists the delegates, the schedule, and the note for each entry. Each entry shows a status of **Active**, **Scheduled**, **Expired**, or **Disabled**, and entries starting or ending within the next week show how many days remain.

Each delegate is emailed when you appoint them, and again when you change or remove the delegation. You are not emailed for changes you make yourself.

### Schedule a delegation

Turn on **Schedule this delegation** to limit the delegation to a window, then set **Starts**, **Ends**, and **Timezone**. The start must be in the future and must come before the end. Leave the option disabled for a delegation that is active immediately and indefinitely.

Veza does not limit how long a window can be, and it accepts overlapping delegations. When windows overlap, the delegates from every active delegation apply.

### Change or remove a delegation

Use **Edit** on a delegation row to change its delegates, note, or schedule. Editing also exposes an **Enabled** toggle, which lets you keep a delegation configured while making it inactive.

Use **Remove** to delete a delegation. The delegates in it stop being added as approvers on your behalf.

## Manage delegations for another user

Administrators can set up and manage delegations for any user, which is useful when someone is already unavailable.

1. Go to **Lifecycle Management** > **Settings** > **Access Request Delegations**.
2. Select a **User**.
3. Add, edit, or remove delegations using the same table and options described above.

## What a delegate can do

A delegate approves as themselves, and Veza records the action as made on the original approver's behalf:

* A banner on the request details states that the viewer is acting on behalf of another approver, and that any action they take is recorded that way.
* The approval note on the request identifies the delegate and the approver they acted for.
* The original approver receives a copy of the notification when a delegate approves or rejects a request on their behalf.

A delegate is credited with the approval categories of the approver who delegated to them, so a step that requires a particular category of approver can be satisfied by the delegate.

## Behavior to plan for

**Delegation applies to all of your approvals.** It cannot be scoped to particular access profiles or catalog items.

**Delegation does not chain.** If a delegate has delegates of their own, those users are not added to your requests. Only your own delegates are added.

**Requests already waiting for you are covered.** Approvers are re-evaluated whenever a request is read or acted on, so a new delegate can act on requests that were already pending. When a scheduled window opens, the request list can take up to five minutes to show the change; this affects the list only, not who is permitted to approve.

**Some delegates are excluded automatically.** A delegate who is the beneficiary or the creator of a particular request is not added as an approver for it, which preserves self-approval controls. A delegate on the [Deny Approver List](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#deny-approver-list) is not added to any request.

**Delegates are matched by email.** Veza resolves a delegate from their identity to their Veza user account using the email address. On a tenant that matches users to identities by another attribute, such as employee ID, a delegate whose identity email differs from their Veza login email cannot be resolved.

## Requirements and limits

Both the delegator and the delegate need Veza user accounts. Delegation references Veza user IDs rather than Lifecycle Management identity IDs, so a user who has a Lifecycle Management identity but has not yet signed in to Veza cannot be selected as a delegate.

A single delegation can name up to 50 delegates, and its note can be up to 1024 characters. You cannot delegate to yourself, and you cannot name the same delegate twice in one delegation.

Delegation is part of Access Requests and is enabled for each tenant along with it. Access Requests must be enabled for your tenant, and the **My Delegations** page appears in Access Hub only when it is.

## Related documentation

* [Approve access requests](/4yItIzMvkpAvMVFAamTf/features/access-request/approve-access.md)
* [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md), including the Reviewer Delegation List, whose entries also apply


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/my-delegations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
