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

# Request and manage your access

Request, track, and manage access in Veza, for yourself or on behalf of others.

Request access to applications, entitlements, and resources in Veza, track your pending requests, and manage access you no longer need. You can request access for yourself or on behalf of someone else.

{% hint style="info" %}
**Quick Start**: To browse the catalog and submit requests, see [Access Hub Catalog](/4yItIzMvkpAvMVFAamTf/features/access-hub/catalog.md). The sections below cover request workflows, status tracking, and advanced features in more detail.
{% endhint %}

For an overview of Access Requests concepts and capabilities, see [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md).

## What you can do with Access Requests

With Access Requests, you can:

* Request access to applications, entitlements, and resources
* Track the status of your pending requests
* View your access history
* Revoke access when it's no longer needed
* Respond to requests for additional information

### Requester versus beneficiary

In Veza Access Requests, there are two key personas in the access request process:

* Requester: The person who creates and submits the access request
* Beneficiary: The person who receives the access being requested

In many cases, you are both the requester and the beneficiary (requesting access for yourself). This is called a first-party access request. However, Veza Access Requests also supports scenarios where you request access on behalf of someone else. This is called a third-party access request.

For more about Access Request concepts and workflows, see the [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md) document.

## Accessing the Catalog

To access the Access Request Catalog:

1. Log in to Veza
2. Navigate to the **Access Hub.**
3. Select **Catalog** from the navigation menu

## Catalog interface

The catalog interface offers two viewing modes. You can switch between views using the toggle in the upper-right corner of the catalog:

### Card view

* Displays catalog items as visual cards
* Shows the requestable item with name, description, and labels
* Useful for browsing available options

### Table view

* Presents catalog items in a tabular format
* Shows additional details, including entitlements
* Useful for comparing multiple catalog items

## Finding the access you need

The catalog displays all catalog items you're eligible to request based on your user attributes.

### Filtering and searching

To find specific access in the catalog:

* **Search**: Enter keywords in the "Search apps" field to search by name or description
* **Categories**: Filter by catalog item type: Apps, Bundles, Tickets, or REST Payloads
* **Apps**: Filter by specific integration or application (for example, Snowflake, AWS, Okta, Salesforce)
* **Owner**: Filter by items owned by you ("Me") or someone else
* **Labels**: Filter by assigned labels (for example, department, function, sensitivity level)

### Viewing access details

To view detailed information about a catalog item:

1. Select a card or row in the table
2. The details panel displays:
   1. Description
   2. Included entitlements
   3. Related resources
   4. Access duration options
   5. Approval requirements

This information helps you understand what access you're requesting and what approvals are required.

### Understanding Related Entitlements

When viewing request details, you may see "Related Entitlements" information:

* These show the specific permissions included in a catalog item
* They help you understand what access you're requesting
* They provide context for approvers reviewing your request

To view related entitlements:

1. Select a request or catalog items
2. Look for the Related Entitlements section
3. Expand any item to see more details

## Submitting Access Requests

### Standard access request (for yourself)

To request access to a catalog item:

1. Locate the desired item in the catalog
2. Select the card or row to open the details sidebar
3. Select **Request** in the sidebar
4. In the request form, configure:
   * **Request for**: Verify your user account is selected (you are the beneficiary)
   * **Explanation**: Select a reason from the dropdown (required) - options are configured by administrators
   * **Comments**: Add additional context or business justification (required)
   * **Duration** (if JIT access is enabled): Select access duration:
     * **Preset options**: One Hour, One Day, One Week, 30 Days, 90 Days, or Never Expires (availability depends on policy)
     * **Other**: Specify custom duration with numeric value and time period (Hours, Days, Weeks, or Months)
5. Select **Request Bundle** (for Access Profiles) or **Request App** (for individual applications)

After submission, a notification confirms that your request is being processed. The item may disappear from the catalog view. Track status on the **Catalog** > **Requests** page.

### Requesting access on behalf of others

Who you can request access for is set tenant-wide, by the **Request on behalf of others** setting. Under **Managers only (self and direct reports)**, the default, the **Request for** field offers you and your direct reports. Under **Everyone**, it offers any identity in the tenant. If the person you need appears in neither case, ask an administrator which option your tenant uses. See [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#request-on-behalf-of-others).

To request access for someone else:

1. Locate the desired item in the catalog
2. Select the card or row to open the details sidebar
3. Select **Request** in the sidebar
4. In the **Request for** field, select or search for the person who needs the access (the beneficiary)
5. Select an **Explanation** from the dropdown
6. Add a **Comment** with a business justification explaining why this person needs the access
7. If applicable, select an access **Duration**
8. Select **Request Bundle** or **Request App** to submit

### Understanding access duration

When submitting a request, the available duration options are controlled by the Access Request Policy associated with the catalog item. Depending on policy configuration, you may see:

* **Preset options**: One Hour, One Day, One Week, 30 Days, 90 Days, or Never Expires
* **Custom duration** ("Other"): Specify a numeric value and time period (Hours, Days, Weeks, or Months)

Not all catalog items offer permanent ("Never Expires") access. This depends on the policy. Some items may require time-limited access only, where access is automatically revoked after the specified duration. This is known as Just-in-Time (JIT) access.

{% hint style="info" %}
**JIT access is not a separate request type**. It is a policy-enforced behavior. When a catalog item's policy mandates time-limited access, the duration field is required and permanent access is not available. See [Managing Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#access-duration-and-time-limited-access) for details on how policies control access duration.
{% endhint %}

## Tracking your requests

### Viewing request status

To check the status of your requests:

1. Navigate to **Access Hub** > **Catalog** > **Requests**
2. View all your current and historical requests in two tabs:
   * **Pending**: Active requests awaiting action or processing
   * **Completed**: Finished requests (approved, rejected, canceled, or completed)

The requests table displays:

* **Name**: The catalog item requested
* **Apps**: Target application(s)
* **Request For**: The beneficiary (user receiving the access)
* **Request By**: The requester who submitted the request
* **Date Requested**: When the request was submitted
* **Entitlement**: The specific entitlements requested
* **Status**: Current state (color-coded)
* **Actions**: Available actions for the request

For a complete list and explanation of request states, see [Access Request Lifecycle](/4yItIzMvkpAvMVFAamTf/features/access-request.md#access-request-lifecycle).

### Request details

To view detailed information about a request:

1. From the **Requests** page, select any request row
2. The request details sidebar opens, showing:
   * **Beneficiary**: Displayed as the page title with entity icon (not as a labeled field)
   * **Reason**: Business justification
   * **Request Type**: Grant or Revoke
   * **Request Source**: How the request was initiated
   * **Created By**: User who submitted the request
   * **State**: Current status with color-coded tag
   * **Target Entities**: Expandable list of requested access
   * **Created At**: Submission timestamp (relative time)
   * **Completed At**: Completion timestamp if applicable
   * **Revoke At**: JIT expiration time if applicable
3. Select **Details** to open the full request details page with additional tabs:
   * **History**: Chronological record of all actions and state changes
   * **Events**: Technical execution details
   * **Access Plan**: High-level actions performed to fulfill the request
   * **Entitlements**: Specific access granted or revoked (shown in the Access Hub for Access Profile requests, and for any request that carries target entities)

{% hint style="info" %}
The Entitlements tab appears in the Access Hub for requests that carry requested entitlements: Access Profile (Bundle) requests and application or catalog-derived requests with target entities. It is not shown for Catalog Definition requests that have no target entities. The Lifecycle Management admin interface shows only the History, Events, and Access Plan tabs.
{% endhint %}

### Request visibility

Unless your Veza role carries tenant-wide read access, the **Requests** page lists a request only when at least one of the following is true:

* You are the identity the request was created for.
* The identity the request was created for is one of your direct reports.
* You created the request.
* You are the beneficiary.
* You are a current approver on the request.
* You are a watcher on the request.

One further case widens the list. When the tenant's [Request on behalf of others](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#request-on-behalf-of-others) setting is **Everyone**, filtering the page to a particular beneficiary shows that beneficiary's requests whatever your relationship to them, including requests somebody else created for them. The relaxation applies only to a beneficiary you name in a filter. An unfiltered **Requests** page still lists only the requests you are related to.

The **Administrator** and **Remediation Owner** roles carry tenant-wide read access to access requests. Holders of those roles see every request, regardless of their relationship to it. For role capabilities, see [User Roles and Permissions](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md).

### What a manager can see

Managers get one additional slice of visibility, and it is scoped tightly.

* A manager sees the requests created for their **direct reports**, alongside their own requests. No configuration is required beyond the manager relationship itself.
* The scope is **one level deep**. Requests created for a report's own reports remain hidden from you, because request visibility does not walk the management chain.
* Direct reports are derived from the manager attribute on each identity in Lifecycle Management, which the identity source populates. A manager whose reports carry no manager attribute sees no additional requests.
* Manager visibility is a **read** scope. Seeing a report's request does not make you an approver on it. Approval routing is configured separately in the Access Request Policy; see [Beneficiary Manager approvals](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#beneficiary-manager-approvals).

{% hint style="info" %}
**A request can open from a link and still be absent from the list.** The check that guards an individual request is slightly wider than the one that builds the **Requests** list: it also matches a manager by email across the beneficiary's identity records in every Lifecycle Management policy. A manager whose approver-of-record account differs from the account they sign in with can therefore open a report's request directly, or from a notification link, while the same request does not appear in their **Requests** list. Reconciling that manager's identity records across policies removes the discrepancy.

A past approver reaches the same outcome by a different route: someone who approved an earlier step and has since dropped out of the current approver list — commonly a delegate — can still open the request they acted on from a link or a notification, even though it does not appear in their **Requests** list.
{% endhint %}

Administrators control which team members a manager sees in the **My Team** dashboard, including the **Hide Contractors** and **Hide Non-Human Identities** filters. Those controls are documented in [Manager Visibility Settings](/4yItIzMvkpAvMVFAamTf/features/access-hub/settings.md#manager-visibility-settings).

## Managing active requests

### Responding to information requests

If an approver requests more information, the request state changes to "Needs More Information" and you receive a notification.

To respond:

1. Navigate to **Access Hub** > **Catalog** > **Requests**
2. Locate the request with state "Needs More Information"
3. Select the request to open details
4. Review the approver's request for additional information (shown in the History tab)
5. Select **Re-request**
6. Enter the requested details in the **Reason** field
7. Confirm the action to send the request back for approval

The request returns to "Initial" and re-enters the approval workflow from its first step. Approvals already given on the request are discarded, so every required approver acts again, and the approvers for the first step are notified.

For more details on the information request workflow, see [Access Request Lifecycle](/4yItIzMvkpAvMVFAamTf/features/access-request.md#access-request-lifecycle).

### Canceling requests

You can cancel a request while it is in one of four states: **Waiting For Approval**, **Needs More Information**, **Plan Selected**, or **Conflict Pending**. A request that has finished, or that stopped in **Errored**, cannot be canceled. To retry an errored request, re-request it instead.

To cancel a request:

1. Navigate to **Access Hub** > **Catalog** > **Requests**
2. Locate the request you want to cancel
3. Select the request to open details
4. Select **Cancel**
5. Optionally provide a reason for cancellation
6. Confirm the cancellation

The request state changes to "Canceled" and any pending approvals are terminated. Canceled requests remain visible in your request history for audit purposes.

### Request notifications

Access Request notifications are opt-in. Nothing is sent until an administrator configures a notification for an event, so which of the following you receive depends on your organization's configuration:

* When your request is submitted
* When the status changes
* When an approver requests more information
* When your request is approved or rejected
* When access is successfully provisioned

Two email sends are exceptions, and arrive regardless of the configured recipients:

* If someone submitted a request on your behalf, you are emailed when that request is created, completed, or failed.
* If you are newly assigned as an approver on a request, you are emailed about the assignment.

Notifications are delivered through:

* **Email**: to requesters, beneficiaries, approvers, watchers, and custom addresses
* **Slack**: through the Slack App (direct messages to approvers) or Slack Webhooks (channel notifications)

For more information about notifications, see [Access Request Notifications](/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md).

## Managing request watchers

Watchers are users who receive notifications about access request status changes, even if they're not the requester, beneficiary, or approver. Adding watchers helps keep additional stakeholders informed about important requests.

### What watchers receive

Watchers receive notifications for these events:

* Request state changes (submitted, approved, rejected, completed)
* Approval or rejection actions
* Request completion or successful access provisioning
* Request errors or failures
* Additional information requests from approvers

The specific delivery channels (email, Slack) depend on your organization's notification configuration. For details, see [Access Request Notifications](/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md).

### Use cases for watchers

Common scenarios for adding watchers include:

* **Compliance Officers**: Monitor sensitive access requests
* **Security Teams**: Track high-privilege access grants
* **Team Leads**: Stay informed about team member access changes
* **Project Managers**: Monitor access for project resources
* **Audit Personnel**: Maintain awareness of access changes for specific systems

### Who can manage watchers

Every Veza role carries the permission to manage watchers, so no role-based restriction applies. In practice you manage a request's watchers from its details page, which you reach from your **Requests** or **Assigned Requests** page — see [Request visibility](#request-visibility) for which requests appear there.

### Adding watchers to a request

To add watchers to an access request:

1. Navigate to the request details page:
   * From **Access Hub** > **Catalog** > **Requests**, select the request
   * Or from **Catalog** > **Assigned Requests** if you're an approver
2. In the request details page header, select the **"Manage Watchers"** button
3. In the **"Manage Watchers"** modal:
   * Select the **"Add Watcher"** dropdown
   * Search for and select the user you want to add
   * The user appears in the watchers table below
4. Select **Save** or **Close** to apply changes

{% hint style="info" %}
**Watcher Permissions**: Watchers receive notifications about the request and see it listed on their **Requests** page. Being a watcher does not by itself grant any action on the request — watchers cannot approve, reject, or otherwise act on it unless they are also designated as approvers.
{% endhint %}

### Removing watchers from a request

To remove a watcher:

1. Select **"Manage Watchers"** on the request details page
2. In the watchers table, locate the user you want to remove
3. Select the remove icon next to their name
4. Select **Save** or **Close** to apply changes

## Managing your access

### Viewing your access

To view your current access and entitlements:

1. Navigate to **Access Hub** > **My Access**
2. Review your access overview, including applications, entitlements, and roles across connected systems
3. Select any item to view detailed entitlements and permissions

The **My Access** page shows all your current access across systems, while **Catalog** > **Requests** shows the history of access requests you've made. Use My Access to understand what you currently have, and Requests to track request status and history.

{% hint style="info" %}
**Availability**: My Access is shown by default, but an administrator can hide it from the **Product Visibility** settings in Access Hub. Its availability also depends on your tenant's licensing. If you don't see My Access in the navigation, contact your Veza administrator.
{% endhint %}

### Revoking access

**Revoke Access** appears on a request that has reached **Completed**, for the requester, the beneficiary, and anyone who is or was an approver on it. Holding the Administrator role does not grant the action on its own: an administrator who has no relationship to the request does not see it.

The action is not offered at all for [Application Catalog Definitions](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md#application), and it is unavailable while a revoke is already pending on the request.

To revoke access that you no longer need:

1. Navigate to **Access Hub** > **Catalog** > **Requests**
2. Locate the completed request for the access you want to revoke
3. Select the request to open details
4. Select **Revoke Access** button
5. Provide a reason for the revocation
6. Confirm the revocation

Confirming schedules the revocation rather than performing it immediately. The request stays in **Completed** until Veza runs the revoke, then moves to **JIT Revoked** once the access is removed. A request fulfilled through an ITSM ticket passes through **Revoke Selected** and **Revoke External Running** first, while the revoke ticket is open. Every step is logged in the request history for audit purposes.

For more information on the revocation process, see [Access Request Lifecycle](/4yItIzMvkpAvMVFAamTf/features/access-request.md#access-request-lifecycle).

### Understanding access expiration

Just-in-time access requests are time-limited after being granted. The associated access automatically expires after the specified duration. You can view the expiration date in the request details. To extend access, submit a new request.

## General guidelines

For effective use of the Access Request system:

* **Provide Clear Justifications**: Include specific business reasons for access requests.
* **Request Minimal Access**: Request only what you need for your role.
* **Specify an Appropriate Duration**: For temporary needs, specify an appropriate time period.
* **Check Existing Access**: Review your current access before requesting new access.
* **Respond Promptly**: Address information requests quickly to avoid delays.
* **Revoke Unneeded Access**: Proactively revoke access when no longer needed.
* **Be Specific When Requesting for Others**: When requesting on behalf of someone else, clearly explain why they need the access.

## Related documentation

* [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md): Core concepts and workflows
* [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md): Policy structure and components
* [Approving Access Requests](/4yItIzMvkpAvMVFAamTf/features/access-request/approve-access.md): Guide for approvers


---

# 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/request-manage-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.