> 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-hub/catalog.md).

# Access Request Catalog

Instructions for requesting, tracking, and managing access in Veza, for yourself or on behalf of someone else

## Overview

You can use the Catalog in Veza Access Hub to:

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

### Requesters and beneficiaries

In Veza, there are two key roles in the access request process:

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

In many cases, you are both the requester and the beneficiary, because you are requesting access for yourself. Veza also supports requesting access on behalf of someone else, in which case you are the requester and they are the beneficiary.

### Understanding access expiration

Time limited just-in-time (JIT) access will automatically expire after the specified duration. You can view the expiration date in the request details. If you need to extend the access, you'll need to submit a new request.

## Accessing the catalog

{% hint style="info" %}
The Catalog is only visible to users who meet all of the following conditions:

* Access Requests is enabled for the organization
* The user appears in an identity source connected to a Lifecycle Management policy (e.g., they exist in Okta or your HRIS system that the policy syncs from)
* The Catalog page is enabled in **Access Hub** > **Settings** > **Product Visibility**

If you don't see Catalog in the navigation sidebar, contact your Veza administrator to verify these requirements.
{% endhint %}

To browse the Access Request Catalog:

1. Log in to Veza
2. Click **Access Hub** in the Products section of the navigation sidebar
3. Select **Catalog** from the navigation sidebar

The Access Hub **Catalog** section includes four pages you can use to request access and manage pending requests:

* **Catalog**: Browse available applications and bundles. Users with admin role can view all applications and bundles within the organization; while users with non-admin roles can only view the applications and bundles available for them.
* **Requests**: For end users, view the status of requested apps and bundles.
* **Assigned Requests**: For end users, review requests assigned to you for approval.
* **My Delegations**: Appoint delegates who can approve access requests alongside you, on a schedule or indefinitely. See [Delegate access request approvals](/4yItIzMvkpAvMVFAamTf/features/access-request/my-delegations.md).

## Browsing the catalog

Use the **Access Hub** > **Catalog** page to browse the apps you can request access to.

* Click a requestable item to view more details, such as the related entitlements and description.
* Search apps, or filter by categories, status, apps, owner, or labels
* Catalog tiles represent either applications (individual apps you can request access to) or access profiles (pre-configured bundles of entitlements across one or more applications). Click any tile to see the specific entitlements included.
* **Popular** and **All** are separate catalog pages, reached from the sections on the catalog landing page. They are not filter values.

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

* Card View: Shows requestable items as visual cards, including the name, description, and labels. Useful for browsing available options.
* Table View: Presents requestable items in a tabular format with additional details, including entitlements. Useful for comparing several items.

### Filtering and searching

To find specific access:

* **Search**: Enter keywords to search by name or description
* **Categories**: Filter by item type. The options are Apps, Bundles, Tickets, REST Payloads, XML Payloads, and SQL Commands
* **Status**: Filter by request status. The only two options are **Available** and **Pending**
* **Apps**: Filter by the specific system or application, such as Snowflake, AWS, or Okta
* **Owner**: Filter by items owned by you or by someone else
* **Labels**: Filter by assigned labels, such as department or function

### Viewing access request details

To view detailed information about an access profile:

1. Click on a profile card or row in the table
2. The details panel will show extra information to help you understand what access you're requesting and what approvals will be required, including any:
   * Description
   * Included entitlements
   * Related resources
   * Access duration options
   * Approval requirements

## Submitting access requests

### Standard access request (for yourself)

1. Click on the desired profile in the catalog to open the sidebar
2. Click **Request** in the sidebar
3. In the request form:
   * **Request for**: Verify that the request is for the intended user account
   * **Explanation**: Choose a reason from the list. The field is not required, and it preselects the first available reason. An administrator can hide it entirely for a given item.
   * **Comments**: Enter context or justification. This field is required by default, but an administrator can make it optional. Both its requirement and its label are configured per Access Profile or catalog definition, so the field can appear under a different name.
   * **Duration**: For temporary (just-in-time) access, select a preset duration or choose **Other** to specify a custom duration
4. Click **Request Bundle** or **Request App** (depending on the item type) to submit the request

After requesting access, a notification will indicate that your request is being processed, and the tile will be removed from the catalog. You can review the status on the **Catalog** > **Requests** tab.

### Requesting access on behalf of others

If you have permission to request access for others:

1. Click the desired profile in the catalog to open the sidebar
2. Click **Request** in the sidebar
3. In the request form:
   * **Request for**: Select the person who needs the access (the beneficiary)
   * **Explanation**: Choose a reason from the dropdown
   * **Comments**: Enter a business justification explaining why this person needs the access
   * **Duration**: Select the appropriate access duration if JIT is configured
4. Click **Request Bundle** or **Request App** to submit

### Just-in-time (JIT) access request

For time-limited access:

1. Follow the steps for a standard access request
2. Under **Duration**, select a preset option: **One Hour**, **One Day**, **One Week**, **30 Days**, **90 Days**, or **Never Expires**. To specify a custom duration, select **Other**
3. If you selected **Other**, enter a numeric value and select the time period: **Hours**, **Days**, **Weeks**, or **Months**
4. Click **Request Bundle** or **Request App** to submit

{% hint style="info" %}
**Note:** The available duration options and your ability to customize the duration may be restricted by the Access Request Policy associated with the access profile. Some policies enforce specific duration limits or require administrator-defined presets.
{% endhint %}

## Tracking your requests

Use the **Access Hub** > **Catalog** > **Requests** page to check the status of requested apps or bundles of entitlements.

The requests you can see depend on your role and your relationship to each request. A request is visible to you if any one of the following applies:

* You created it (you are the requester)
* You are the beneficiary (someone requested access for you)
* You are designated to approve it
* You are a watcher on it
* The request is for one of your own Lifecycle Management identities
* The request is for one of your direct reports

Administrators and users holding the `remediation_owner` role can read every request in the tenant.

### Viewing request status

To check the status of your requests:

1. Navigate to **Access Hub** > **Catalog** > **Requests**
2. Choose the **Pending** or **Completed** tab
3. View all your current and historical requests with their status:
   * **Initial**: Request created but not yet submitted for approval
   * **Waiting for Approval**: Awaiting approver action
   * **Needs More Information**: Requires additional information from you
   * **Plan Selected**: Access plan has been selected and is being prepared for implementation
   * **Completed**: Successfully fulfilled
   * **Errored**: Failed during implementation
   * **Rejected**: Denied by approvers
   * **Canceled**: Withdrawn by you
   * **JIT Revoked**: Time-limited access has been automatically revoked after expiration
   * **External Running**: Request is being processed by an external system
   * **Revoke Selected**: A revoke has been initiated, either manually or by the JIT timer, and is being carried out. No external revoke ticket exists yet.
   * **Revoke External Running**: A revoke ticket has been created in the external system, and the request waits for an administrator to mark that ticket resolved before the access is removed.
   * **Conflict Pending**: Approval is blocked because no eligible approver remains for the current step, so that step cannot be satisfied on its own. Nothing has failed. The request waits for a tenant administrator to reassign it to a different approver or to cancel it.
4. You can filter either tab to find requests by type, apps, status, or the requester or beneficiary.

### Viewing request details

To view more information about a request:

1. Click on any request from your list
2. The details panel will include:
   * The request status
   * The request duration (Permanent or time-limited)
   * The user who requested access
   * The user the request is for
   * The request date
   * Users needed for approval

Click the "expand" icon in the details sidebar to view details in full screen. In this view, you can choose a tab to get more information:

* **History**: Any changes to the request, including the action, message, and current/previous state
* **Events**: Associated lifecycle management events, with options to filter by failed events, event type, or date
* **Access Plan**: Summary of actions performed, including the action type and status
* **Entitlements**: Details about the requested app entitlements. This includes the source app name (e.g., Active Directory), entitlement (e.g., ActiveDirectoryGroup), and entitlement actions (e.g., view related entitlements)

## Managing active requests

### Responding to information requests

If an approver requests more information:

1. Navigate to **Access Hub** > **Catalog** > **Requests** and locate the request marked **Needs More Information**
2. Click the request to view what information is needed
3. Enter the requested details
4. Resubmit the request

{% hint style="info" %}
**Note:** Access Request notifications are opt-in. Veza sends nothing until an administrator configures notifications for the relevant event, so check the **Requests** page rather than relying on an email or a Slack message.
{% endhint %}

### Canceling requests

To cancel a pending request:

1. Navigate to **Access Hub** > **Catalog** > **Requests**
2. Locate the request you want to cancel
3. Choose **Cancel** from the row actions
4. Confirm the cancellation

### Reassigning an approver

A request in the **Conflict Pending** state has no eligible approver and cannot advance on its own. A tenant administrator resolves it by choosing **Reassign approver** from the row actions and selecting a different approver, or by canceling the request.

## Managing request watchers

Watchers are users who receive notifications about an access request as it moves through approval, even when they are not the requester, beneficiary, or approver. Adding a watcher keeps another stakeholder informed about a request without giving them a say in it.

### Who can manage watchers

**Manage Watchers** appears on the request details page for any user who can open that request. Because a request is visible to its requester, beneficiary, approvers, and existing watchers, as well as to administrators, each of those users can also add and remove its watchers.

### Adding a watcher

1. Open the request details page:
   * From **Access Hub** > **Catalog** > **Requests**, select the request.
   * If you are an approver, from **Access Hub** > **Catalog** > **Assigned Requests**, select the request.
2. Select **Manage Watchers**.
3. In the **Manage Watchers** dialog, use the **Add Watcher** list to search for and select a user.

The watcher is added as soon as you select the user, and appears in the **Watcher** table below the list. There is no separate save step.

{% hint style="info" %}
A watcher can view the request and receive notifications about it, but cannot approve, reject, or otherwise act on it, unless they are also a designated approver.
{% endhint %}

### Removing a watcher

1. On the request details page, select **Manage Watchers**.
2. In the **Watcher** table, find the user you want to remove.
3. Select **Remove** in that row.

The watcher is removed as soon as you select **Remove**. There is no separate save step.

### What watchers receive

Access Request notifications are opt-in, so a watcher receives a message only for the events an administrator has configured, over the channels that configuration specifies. Depending on that configuration, a watcher can be notified when a request changes state, when an approver approves or rejects it, when it completes or fails, and when an approver asks for more information.

For the events available and how to configure them, see [Access request notifications](/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md).

### When to add a watcher

Watchers suit cases where someone needs visibility into a request without a role in deciding it, such as:

* A compliance or audit function tracking access to a regulated system
* A security team monitoring grants of high-privilege access
* A team lead following access changes for their team
* A project owner following access to project resources

## Managing your access

### Viewing your access

To view your current access:

1. Navigate to **Access Hub** > **My Team**
2. Click **View My Access**
3. Click on any resource to view more information about specific resources you have access to

### Revoking access

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. Choose **Revoke Access** from the actions menu
4. Provide a reason for the revocation
5. Confirm the revocation

## Related documentation

* [Access Hub Overview](/4yItIzMvkpAvMVFAamTf/features/access-hub.md): Introduction to Access Hub features
* [Access Hub Configuration](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md): Administrator setup guide
* [Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md): Creating and managing access profiles
* [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management.md): Policy-driven automation


---

# 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-hub/catalog.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.