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

# Approve access requests

Review, approve, or reject access requests assigned to you as an approver in Veza.

Review, approve, or reject access requests assigned to you as an approver in Veza Access Requests.

## Overview

As an approver, you govern the granting of access requests during the approval workflow.

You're responsible for:

* Reviewing access requests assigned to you
* Evaluating the business justification and requested access
* Making informed decisions to approve or reject requests
* Requesting additional information when needed
* Documenting your decision rationale
* Proactively performing revocation of the access request, if evidence has come to light that access was granted erroneously

## Prerequisites

Before you can approve access requests, confirm the following.

### Access to Veza

Approvers reach Veza through your organization's single sign-on (SSO) provider. That SSO login creates the Veza user account that approval routing references, so an approver who has not signed in through SSO cannot be assigned to a request. See [Set up Access Requests](/4yItIzMvkpAvMVFAamTf/features/access-request/enable-access-requests.md).

### Authorization to act on a request

No minimum platform role gates the approve action. Veza authorizes each decision against the request itself. You can approve, reject, or ask for more information on a request when either of the following is true:

* You are one of the approvers resolved for that request, whether through an approver category, a named user or group in the policy, a [delegation](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#reviewer-delegation), or dynamic resolution.
* You are an administrator and the policy routes the approval to administrators, either through the Admin approver category on the step or through the admin approval settings. Administrators are resolved onto the request like any other approver category, so an administrator whom the policy does not route in is not an approver on that request and cannot approve it.

Approvers do not require Veza console access. Being named on the request is what grants the ability to act on it.

Two administrative actions are separate from approval and do not depend on the approver list: an administrator can cancel a request, and can reassign a request that is stuck in Conflict Pending to a different approver.

Platform roles determine which requests you can see and export, not which requests you can approve:

| Capability                                         | Roles that have it                                                                                                                                          |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| See the requests assigned to you                   | Any authenticated user                                                                                                                                      |
| See every request in the tenant, not only your own | **Administrator** and **Remediation Owner**                                                                                                                 |
| Export the access request table                    | **Administrator** and **Operator**. An Operator exports only the requests that their own table shows. An Administrator exports every request in the tenant. |

{% hint style="info" %}
**API clients**: An OAuth2 App that acts on access requests requires the `lcm:access-requests:manage` scope. See [OAuth2 Apps](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-apps.md#scopes).
{% endhint %}

### Approval interface

Use the Access Hub for approvals: it provides a dedicated interface for reviewing and acting on access requests. The Admin Console is better suited for administrative tasks such as configuring policies, managing profiles, and viewing system-wide request analytics.

Access requests can be approved from two interfaces, depending on your role and needs:

* **Access Hub** (recommended): Interface designed for approvers, focused on reviewing and acting on requests
* **Admin Console**: Administrative interface with full request management capabilities and system-wide visibility

#### Switching between interfaces

If you have access to the Access Hub as well as the Admin Console, the left navigation shows a single toggle button at the bottom of the sidebar, marked with a left-right arrows icon. The button has no separate name in the interface. Its label states where it takes you, and changes with the view you are currently in:

* From the Admin Console, it reads **Switch to Access Hub**
* From the Access Hub, it reads **Switch to Admin Console**

Select the button to move to the other interface. It appears only for users who have Access Hub access. If you do not see it, your role limits you to one interface.

## Approval process

Understanding how approvals work in Access Requests helps you review and act on requests.

### Approval steps

Approvals can require multiple sequential steps based on governance policies configured at the policy level:

1. Each step must be completed in order
2. Multiple approver categories may be required within a step
3. All required approvers in a step must approve before moving to the next step

For example, a high-security resource might require:

* **Step 1**: Manager approval
* **Step 2**: Security team approval
* **Step 3**: App Owner approval

Each step must be completed before the request progresses to the next level.

### Approver categories

You may be designated as an approver based on several categories:

| Category                 | Description                                                                                                                                                                                                                                                                                                                                                                                       |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Admin**                | System administrators with global approval rights                                                                                                                                                                                                                                                                                                                                                 |
| **Access Profile Owner** | Owners of the requested Access Profile (catalog item)                                                                                                                                                                                                                                                                                                                                             |
| **Beneficiary Manager**  | Manager of the user who receives the access (the beneficiary). Whether a manager resolves depends on the identity source. See [Beneficiary Manager approvals](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#beneficiary-manager-approvals).                                                                                                                                    |
| **App Owner**            | The owners recorded on the integration behind the requested access. Veza resolves them from the requested Access Profile, through that profile's data sources, to the parent integration, then expands the integration's owner list, resolving groups to their members. See [Manage Integration Permissions](/4yItIzMvkpAvMVFAamTf/integrations/configuration/manage-integration-permissions.md). |
| **Other**                | Specific individuals or Veza Groups explicitly assigned as approvers in a policy                                                                                                                                                                                                                                                                                                                  |
| **Dynamic**              | Approvers resolved at request time based on runtime context, access profile metadata, and lookup tables. See [Dynamic Approvers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-approvers.md).                                                                                                                                                                              |

These categories can be combined within approval steps to create flexible workflows that match your organization's governance requirements.

{% hint style="info" %}
**Dynamic assignment**: You may have been assigned as an approver dynamically (based on your role, department, cost center, or reporting relationship) rather than being explicitly named in the policy.
{% endhint %}

### How dynamic approvers resolve

When an approval step uses the **Dynamic** category, Veza runs the step's transformer pipeline at the moment the request is submitted and stores the resulting approver list on the request. Every later action reads that stored list, which has three consequences:

* Editing the policy or its pipeline does not change the approvers on a request that is already open.
* Submitting the request again resolves the approvers a second time, against the policy as it stands at that moment.
* The requester and the beneficiary are excluded from the result. If nobody remains after that exclusion, Veza records the empty result rather than reporting an error, and the request moves to **Conflict Pending**. An administrator can then reassign or cancel it, or the requester can submit it again.

Administrators can confirm how a pipeline resolves before a request depends on it, using the **Test Configuration** control. For pipeline configuration and testing, see [Dynamic Approvers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-approvers.md#testing-a-dynamic-approver).

## Accessing pending requests

When you're designated as an approver for a request, you receive a notification.

To view and manage requests assigned to you:

1. Log in to Veza and navigate to the **Access Hub**
2. Select **Catalog** from the navigation menu
3. Select **Assigned Requests** to view requests awaiting your approval

The Assigned Requests page displays "Apps and Bundles assigned to you for review" with two tabs:

* **Pending**: Requests awaiting your decision
* **Completed**: Requests you've already processed

### Request information displayed

For each request in the list, you see:

* **Request For**: The beneficiary of the request, the identity that receives the access
* **Target Entities**: What they're requesting access to
* **Comments**: Business justification provided by the requester
* **State**: Current status, such as Waiting For Approval or Needs More Information
* **Created At**: When the request was submitted
* A final, unlabeled column on each row opens a menu of the actions available on that request, including **View details**, **Approve**, and **Reject**

You can filter requests by type, state, or use custom filters to find specific requests.

{% hint style="info" %}
**For Admins**: Requests can also be viewed and managed in the Admin Console, under **Lifecycle Management** > **Access Requests**, which provides system-wide visibility and additional administrative capabilities.
{% endhint %}

## Reviewing request details

To review the details of a request:

1. Select the request from the pending list in **Access Hub** > **Catalog** > **Assigned Requests**
2. The request details panel displays:
   * Requester information and beneficiary
   * Business justification and explanation
   * Requested catalog item or entitlements
   * Requested duration (for time-limited access), which may be adjustable by the approver if the policy allows it (see [Adjusting Access Duration](#adjusting-access-duration))
   * Request history and previous approvals (for multi-step workflows)
   * Related entitlements and their impact
   * Watchers: users receiving notifications about this request (you can add or remove watchers if you have appropriate permissions)

When reviewing a request, consider:

* Is the business justification valid and clear?
* Does the requester need this level of access?
* Is the requested duration appropriate?
* Does this access comply with your organization's policies?
* Are there any potential security or compliance concerns?

## Approval actions

After reviewing a request, you can take one of the following actions:

### Approving a request

To approve a request:

1. Select the request
2. Choose the Approve action
3. Optionally add comments explaining your approval rationale
4. Submit your approval

When you approve a request:

* If you're the final required approver, Veza automatically grants the requested access
* If additional approvals are required, the request moves to the next approval step
* The requester is notified of your approval

### Rejecting a request

To reject a request:

1. Select the request
2. Choose the Reject action
3. Provide a reason for the rejection (required)
4. Submit your rejection

When you reject a request:

* The request workflow ends immediately
* The requester is notified of the rejection and provided with your reason
* No access is granted
* The rejection is logged for audit purposes

### Requesting more information

If you need additional details before making a decision:

1. Select the request
2. Choose the Request More Information action
3. Specify what additional information you need
4. Submit your request

When you request more information:

* The request status changes to "Needs More Information"
* The requester is notified and prompted to provide the requested details
* The approval workflow is paused until the requester responds
* Once the requester provides the information, the request returns to "Waiting For Approval" status

For a complete description of all possible request states and actions, see [Access Request Lifecycle](/4yItIzMvkpAvMVFAamTf/features/access-request.md#access-request-lifecycle) in the Access Requests overview.

## Modifying request parameters

Consider reducing the requested duration if the business justification suggests shorter access is sufficient. For example, if a user requests 7 days to complete a 2-hour task, you might adjust to 1 day to minimize the window of elevated privilege.

Depending on policy settings, you may be able to modify certain request parameters:

### Adjusting access duration

Access Request Policies can allow approvers to modify the requested access duration when approving time-limited (JIT) access requests. This capability is controlled by the policy's `allowApproverToModify` setting.

#### When duration can be adjusted

You can adjust duration if:

* The Access Request Policy has "Allow approver to modify duration" enabled
* The request includes time-limited (JIT) access
* You're approving the request (not just viewing it)

If these conditions aren't met, the duration fields are disabled and show the policy-defined duration.

#### How to adjust duration

When approving a request with adjustable duration:

1. Open the request and select **Approve**
2. In the approval dialog, locate the **Expiration Time** section
3. Adjust the duration using two fields:
   * The number input, which carries the section's own **Expiration Time** label: enter a number (for example, 2, 24, or 7)
   * The period list beside it: select **Hour** or **Day**
4. If you adjust the duration, you see a validation message: "Choose expiration time between \[min] to \[max]"
5. Add a comment explaining why you modified the duration
6. Complete the approval

{% hint style="warning" %}
**Duration Constraints**: The policy defines minimum and maximum duration limits. You cannot set a duration outside these bounds. For example, if the policy specifies a maximum of 24 hours, you cannot approve access for 7 days.
{% endhint %}

For more information about how policies control duration settings, see [Managing Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#access-duration-and-time-limited-access).

## Viewing request history

Each request maintains a complete history of actions and decisions. To view request history:

1. Select the request from your **Assigned Requests** list
2. Select **Details** to open the full request view
3. Navigate to the **History** tab

The History tab shows a chronological record of all state changes: request submission, each approval or rejection, information requests and responses, comments and justifications, and automated system actions (such as auto-approval or JIT revocation).

For more details on the full audit trail, including the Events, Access Plan, and Entitlements tabs, see [Access request history](/4yItIzMvkpAvMVFAamTf/features/access-request/request-history.md).

## General guidelines for approvers

For effective and secure access governance:

* **Review Thoroughly**: Use the [request details panel](#reviewing-request-details) to examine the business justification, requested entitlements, and access duration before making a decision. For Access Profile requests, the Entitlements tab shows the exact groups, roles, and permissions that are granted. See [Access request history](/4yItIzMvkpAvMVFAamTf/features/access-request/request-history.md#entitlements-tab) for details.
* **Respond Promptly**: Unresolved requests can trigger [expiration policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#expiration-policy) that auto-reject, auto-approve, or escalate to other approvers. Responding promptly keeps control of decisions with you rather than deferring them to escalation targets.
* **Document Decisions**: Comments you provide when [approving](#approving-a-request) or [rejecting](#rejecting-a-request) are permanently recorded in the [request history](/4yItIzMvkpAvMVFAamTf/features/access-request/request-history.md#history-tab). Clear rationale helps future reviewers understand past decisions during access reviews and compliance audits.
* **Consider Least Privilege**: If the policy allows it, [adjust the access duration](#adjusting-access-duration) to the minimum needed. For example, reduce a 7-day request to 1 day for a task that takes hours. Time-limited (JIT) access is automatically revoked when the duration expires. Shorter durations reduce the window of risk.
* **Be Consistent**: [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md) standardize approval workflows and duration limits across similar resources. When policies allow discretion (such as adjustable duration), apply consistent standards within those boundaries.
* **Check History**: Review the [History tab](#viewing-request-history) for a chronological record of past actions on the request, including previous approvals, rejections, and information requests.
* **Verify Compliance**: Consider whether the request aligns with your organization's policies. Approving access that violates policy creates audit findings. [Access Reviews](/4yItIzMvkpAvMVFAamTf/features/access-reviews.md) may later flag over-provisioned access for re-certification.
* **Request Clarification**: Use the [Request More Information](#requesting-more-information) action to pause the workflow and ask the requester for additional details. The request remains in "Needs More Information" state until they respond, so nothing is granted while you wait.

## Related documentation

* [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md): request lifecycle, state machine, and concepts
* [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md): approval workflows, JIT access, and expiration policies
* [Requesting and Managing Access](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md): end-user guide for requesters
* [Access Request Notifications](/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md): notification channels and configuration
* [Access request history](/4yItIzMvkpAvMVFAamTf/features/access-request/request-history.md): reviewing the recorded actions, approvals, and state changes for a request

For persistent issues, contact your system administrator or Veza support.


---

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