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

# Set up Access Requests

Enable Veza Access Requests to govern policy-based access grants through an automated request and approval workflow.

Veza Access Requests governs policy-based access grants through an automated request and approval workflow. To enable self-service access requests in your organization, configure the platform components, user roles, identity provider integration, and access governance policies that Access Requests requires.

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

## Overview

To enable Access Requests in your environment, an administrator and target application owners configure several interconnected platform components. Some of these may already be enabled for your tenant:

1. **Early Access Features**: Enable optional features as needed in coordination with Veza Support.
2. **Authentication and User Roles**: Enable Single Sign-On (SSO) for Access Hub user authentication using your identity provider, with appropriate role assignments for requesters, approvers, and administrators.
3. **Identity Provider Settings**: Set your Global IdP configuration to map user and manager relationships using your organization's primary IdP and secondary identity sources.
4. **Access Hub Settings**: Configure the user-facing portal for requesting and managing access.
5. **Enable Integrations**: Configure target application integrations with sufficiently privileged credentials. This enables both Access Requests and Lifecycle Management to provision and deprovision user access.
6. **Define Access Request Policies**: Define approval workflows and access durations.
7. **Create Access Profiles**: Create requestable bundles of entitlements for the Access Catalog.

## Prerequisites

Before configuring Access Requests, confirm that the following platform components are in place.

### Feature enablement

Contact your Veza representative to enable Access Requests for your tenant. Your representative enables the following features:

* **Lifecycle Management**: the core provisioning engine that executes access grants and revocations
* **Access Plans and Access Profiles**: the entitlement bundling and policy engine used by Access Requests
* **Access Requests and Access Hub**: the catalog UI, request workflows, and Access Requests API endpoints
* **Role Definitions**: required for catalog UI components
* **Global Navigation**: the updated Access Hub sidebar that surfaces the Catalog entry point

Feature enablement is handled by Veza Support and typically occurs during initial tenant onboarding.

{% hint style="warning" %}
**Verify feature enablement**: After your Veza representative confirms features are enabled, verify that the **Catalog** link appears in the Access Hub sidebar and that the **Lifecycle Management** section is visible in the admin console. If either is missing, contact Veza Support. Incomplete feature enablement is a common setup issue.
{% endhint %}

### Authentication and user roles

Access Requests operates within Access Hub, which requires SSO authentication for users.

**Single Sign-On (SSO)**:

* SSO must be configured and functional before proceeding (users access Access Hub through your organization's identity provider)
* Veza supports SAML-based SSO with identity providers including Okta, Microsoft Entra ID (Azure AD), and other SAML 2.0 compliant systems
* Test SSO authentication to verify users can successfully log in to Veza before configuring Access Requests

For SSO configuration instructions, see [Single Sign-On Settings](/4yItIzMvkpAvMVFAamTf/administration/administration/sign-in-settings/saml.md).

Local Veza accounts alone are insufficient for Access Requests; Access Hub uses SSO to authenticate users and establish their identity. The SAML NameID must contain the user's email address, and the Issuer ID must exactly match the IdP's EntityID. For detailed requirements, see [Single Sign-On Settings](/4yItIzMvkpAvMVFAamTf/administration/administration/sign-in-settings/saml.md).

{% hint style="warning" %}
**Approver SSO prerequisite**: Users who serve as approvers, such as managers for Beneficiary Manager workflows, must log in through SSO at least once **before** requests that need their approval are submitted. The SSO login creates the Veza user account that approval routing references. If an approver has no Veza user account when a request is created, they cannot be assigned, and a step with no other approver source moves the request to Conflict Pending. See [Beneficiary Manager approvals](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#beneficiary-manager-approvals).
{% endhint %}

**User Roles**:

Different participants in the access request workflow require different role assignments:

* **Administrators**: Require the **Administrator** or **Operator** role for creating Access Profiles, Access Request Policies, and managing system-wide settings.
* **Requesters**: Any user who can authenticate via SSO can request access through the Access Catalog. No special Veza platform role is required.
* **Approvers**: Users who approve requests need only the ability to authenticate via SSO. Approvers review and act on requests in the Access Hub. No Veza console access is required unless they also perform administrative tasks.
* **Access Profile Owners**: Users designated as owners of Access Profiles must be configured in Veza (typically via Global IdP Settings or as Veza local users).

For detailed role capabilities, see [User Roles and Permissions](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md).

### Identity provider settings

Global IdP Settings establish the connection between your SSO provider and Veza, enabling:

* **Access Reviews**: Manager-based reviewer assignment, My Team dashboard for managers in Access Hub, and organizational hierarchy visibility. These use the `manager_identity_property` configured in Global IdP Settings at request time.
* **Access Requests**: Resolving the `identities:me` endpoint so that SSO-authenticated users can see the Access Catalog. This requires `instance_id` and `instance_id_property` to match graph node properties on your identity source.

{% hint style="warning" %}
**Beneficiary Manager approval does not come from Global IdP Settings.** Beneficiary Manager approval steps resolve the manager from the beneficiary's Lifecycle Management identity, which is populated automatically while identities are processed. Configuring Global IdP Settings alone does not enable manager-based approval for Access Requests. Whether a manager resolves depends on the identity source, so check your source against [Beneficiary Manager approvals](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#beneficiary-manager-approvals) before you rely on this category.
{% endhint %}

Configuration requirements:

* **Identity provider integration**: your IdP (Okta, Active Directory, Entra ID) must be integrated with Veza as a data source
* **Manager relationships**: must be populated in your identity provider
* **API access**: administrator API token for configuration

For detailed configuration steps including API examples for Okta and Azure AD, see [Configuring Global IdP Settings](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings.md).

Configure Global IdP Settings before users need the Access Catalog, because the catalog does not load until SSO-authenticated users resolve to graph identities. Manager-based approvals do not depend on this step.

{% hint style="warning" %}
**Instance ID configuration**: The Global IdP settings require `instance_id` and `instance_id_property` values that match properties on your identity provider's graph nodes. With incorrect values, the system cannot resolve users, so the Catalog does not appear or requests fail. Common configurations:

| Identity Provider | `instance_id_property` | `instance_id` value     |
| ----------------- | ---------------------- | ----------------------- |
| Okta              | `okta_org_id`          | Your Okta org ID        |
| Entra ID          | `azure_ad_tenant_id`   | Your Azure AD tenant ID |
| OAA Custom IdP    | `datasource_id`        | The OAA datasource UUID |

To verify your configuration, check that the `identities:me` API returns the current user's identity: `GET /api/private/lifecycle_management/identities:me`. A NotFound response typically indicates incorrect `instance_id_property` or `instance_id` values.
{% endhint %}

### Identity resolution

Every access request resolves the person twice, and both resolutions must succeed. The two hops are independent: a request can clear the first and still provision nothing when the second finds no account in a target system.

[Access Hub Configuration](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md) is the configuration reference for both hops. It carries the [identity flow diagram](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md#architecture-and-identity-flow) and the [per-system configuration points](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md#identity-mapping-configuration-points) for Global IdP Settings, the identity provider integration mapping, Lifecycle Management Identity Settings, and the HR integration. This section explains what those settings resolve at request time.

#### Hop 1: Veza user to policy identity

When a user signs in through SSO, Veza matches their Veza user account to a Lifecycle Management policy identity. That policy identity is what the Access Catalog, catalog visibility rules, and approval routing operate on.

The matching key is **Matching Method**, in the **User to Identity Matching** section of **Lifecycle Management** > **Settings** > **Identity Settings**. It offers two values, and no others:

| Matching Method     | How Veza matches                                                                                                                                                                                                                                                                                                                        |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Email** (default) | Veza matches a policy identity whose `email` equals the signed-in user's email address, or the `email` property on that user's graph node. Veza tries both addresses, so a user whose graph node carries a different address than their sign-in credential still resolves.                                                              |
| **Employee ID**     | Veza reads an employee ID from the signed-in user's graph node, then matches a policy identity whose `employee_id` equals that value. By default Veza reads the `employee_id` property. When you name a property in **Employee ID Property Name**, Veza reads that property first, then its `custom_prop_` variant, then `employee_id`. |

Email and employee ID are the only supported matching keys.

Use the same key everywhere. Global IdP Settings, the identity provider integration mapping, Identity Settings, and the HR integration must agree on email or on employee ID. When they disagree, a user resolves in one place and not in another.

When no policy identity matches, the user has no LCM identity: the Catalog does not appear in the Access Hub sidebar, and `GET /api/private/lifecycle_management/identities:me` returns NotFound.

#### Hop 2: Policy identity to target-system account

Granting access means changing an account in a target system, so Veza resolves an account for the beneficiary in every data source the request touches. For each data source, Veza takes the first result from:

1. The beneficiary's primary or secondary source-of-identity node, when that node belongs to the target data source's provider.
2. An account recorded on the identity by an earlier **Sync Identity** action for that data source.
3. A local user for that identity in the Access Graph, correlated through [Custom Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md) or through native correlation between integration pairs (for example, Active Directory and Azure AD).

The resolved account must also be enabled for Lifecycle Management. An account whose Lifecycle Management flag is off cannot be used to grant or revoke access.

{% hint style="warning" %}
**A data source with no account is skipped, not failed.** When Veza resolves no account in one data source, it records the warning `No local user/account or synced identity found for datasource <name> (<type>)` and drops that data source from the request. The request still moves through approval and reaches **Completed**, and no access is granted in the skipped system. This is the common explanation for a completed request whose access is missing in one application.

Submission fails outright only when every data source is skipped and no provisioning work remains. The rejection quotes the same warning: `No job requests created. No local user/account or synced identity found for datasource <name> (<type>).`
{% endhint %}

#### Beneficiaries of on-behalf requests

Hop 2 resolves the **beneficiary**, not the requester. On a self-service request the two are the same person, so the distinction stays invisible. On a request submitted on behalf of someone else, Veza does not consult the requester's own accounts: it resolves target accounts for the beneficiary named in the **Request for** field.

The two roles therefore have different prerequisites:

* The **requester** needs a Veza user account from SSO and a policy identity from hop 1. Without both, they cannot open the Catalog or submit anything.
* The **beneficiary** needs an active policy identity and a resolvable account in each target data source. A beneficiary without a Veza sign-in can still receive access, because an on-behalf request identifies them by policy identity rather than by Veza user account.

A request for a beneficiary whose policy identity is inactive is rejected at submission with `Identity is not active`. For how the two roles differ elsewhere in the workflow, see [Requester versus beneficiary](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md#requester-versus-beneficiary).

### Access Hub configuration

Access Hub provides the user-facing interface for browsing the Access Catalog, requesting access, tracking requests, and approving requests. Configuration includes:

* Identity Provider mode: selects how Veza maps signed-in users to their LCM identities. This is an API-only value, `AccessHubIdentityProviderSettings.provider_type`; it is not rendered as a control. Set it to the `LCM Identity` value for Access Requests. The Catalog appears in the Access Hub sidebar only in that mode.
* **Identity mapping**: maps SSO-authenticated users to Veza local users and policy identities. See [Identity resolution](#identity-resolution) for what this resolves at request time.
* **Entity type visibility**: control which integration data appears in My Access and My Team views
* **Page visibility**: enable or disable specific Access Hub pages (including the Catalog)
* **Manager visibility**: configure which manager relationships display in the My Team dashboard

{% hint style="warning" %}
**Access Hub Identity Provider mode**: The Catalog page requires the Access Hub Identity Provider to be set to the `LCM Identity` value. When set to the default mode (Access Workflow IdP), the Catalog link does not appear in the Access Hub sidebar, even if all other configuration is correct. There is no control for this in the interface; configure it through the API:

```
PUT /api/private/workflows/access/global_settings/access_hub_idp_settings
{"value": {"provider_type": 1}}
```

Where `provider_type: 1` corresponds to LCM Identity mode. Verify the setting with `GET /api/private/workflows/access/global_settings/access_hub_idp_settings`.
{% endhint %}

For configuration instructions, see [Access Hub Configuration](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md) and [Access Hub Settings](/4yItIzMvkpAvMVFAamTf/features/access-hub/settings.md).

### Source of identity and target applications

Access Requests provisions and deprovisions access through integrations with your organization's systems. Two types of integrations are required:

**Source of Identity**: At least one identity source must be connected to Veza. This is the authoritative source that maps users to their organizational attributes (department, manager, location). Common identity sources include HR systems (Workday), identity providers (Okta, Entra ID), and directory services (Active Directory).

{% hint style="warning" %}
**Enable Lifecycle Management on the identity source provider**: After adding your identity provider integration, you must enable Lifecycle Management on it before creating an LCM policy that uses it as a Source of Identity. Without this step, the LIFECYCLE\_MANAGER-type datasource (required by the LCM policy) is not created, and policy creation fails with a `Data source is not lifecycle management` error (the full message also identifies the data source's id, type, agent type, and name, for example `Type: extractor`).

To enable Lifecycle Management on a Custom OAA provider:

```
PATCH /api/v1/providers/custom/{id}
{"id": "{id}", "provisioning": true}
```

For Okta, Azure, and other native integrations, this is configured through the integration's **Provisioning** settings in the Veza console.
{% endhint %}

**Target Applications**: The systems where access is granted or revoked when requests are approved. Target application integrations must be configured with **sufficiently privileged credentials** to allow:

* Creating and provisioning new user accounts
* Changing user entitlements and group memberships
* Disabling and re-enabling user accounts
* Performing deprovisioning operations

{% hint style="warning" %}
**Permission Requirements**: Insufficient permissions on integration service accounts cause provisioning failures when approved requests are fulfilled. Verify write permissions before proceeding.
{% endhint %}

**Identity correlation**: Application-type provisioning grants entitlements directly in a target system, so the beneficiary's LCM identity must correlate to an account there. [Identity resolution](#identity-resolution) covers how Veza resolves that account, what happens when it resolves none, and which side of an on-behalf request is resolved. Correlation is not required for catalog definition types that do not touch a target account: ServiceNow, Jira, Send REST Payload, Send XML Payload, and Send SQL Command.

For integration-specific permission requirements and setup instructions, see [Lifecycle Management Integrations](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/integrations.md). Each integration guide lists the specific permissions required.

## Step 1: Configure Access Request Settings

Access Request Settings define global, tenant-level configuration that controls how access requests are governed across your organization.

Navigate to **Lifecycle Management** > **Settings** > **Access Request Settings** and configure:

* **Approvals**: who is allowed to approve requests (administrators, Access Profile owners, application owners). Each category has `allow_approval_on_request` and `grant_without_approval` toggles.
* **Access Profiles Settings**: which Access Profiles appear in the Access Catalog. You can allow all profiles, limit by labels, or limit by Access Profile Type.
* **Available Explanations**: predefined reasons that requesters can select when submitting requests (for example, "Project work", "Temporary coverage", "Role change").

For a complete reference of all settings and their configuration options, see [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md).

## Step 2: Define Access Request Policies

Access Request Policies define the rules that govern how individual access requests are processed, specifically the **approval workflow** and the **access duration**.

**Approval workflows** determine who must approve a request before access is granted. A workflow can have multiple sequential steps, each requiring approval from one or more approver categories (such as the beneficiary's manager, the application owner, or a dynamically resolved approver). Workflows can also be configured for auto-approval when human review isn't required.

**Just-in-Time (JIT) access** means access is granted for a limited duration and automatically revoked when the time expires. JIT access reduces standing privilege by granting access only while users actively need it. Policies control the minimum and maximum duration, and whether requesters or approvers can adjust the duration.

To create a policy:

1. Navigate to **Lifecycle Management** > **Settings** > **Access Request Policies**
2. Select **New Access Request Policy**
3. Configure the policy's approval workflow, access duration, and expiration behavior

Policies can be applied at two levels:

* **Access Profile Type level**: all profiles of that type inherit the policy. Use this for consistent governance across similar access types.
* **Individual Access Profile level**: overrides any type-level policy for that specific profile. Use this for exceptions.

For detailed policy configuration including multi-step approvals, expiration actions, and dynamic approvers, see [Managing Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md).

## Step 3: Create and publish Access Profiles

Access Profiles are bundles of entitlements that, when published, appear as requestable items in the Access Catalog. Creating an Access Profile involves selecting the target application entitlements, configuring how the profile appears in the catalog, and making it available for request.

### High-level steps

1. Navigate to **Access Profiles** > **Profiles** and select **Create Access Profile**
2. Select an **Access Profile Type** (for example, Application Entitlements, Business Role). The type determines the profile's behavior, inheritance rules, and default Access Request Policy. See [Access Profile Types](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/access-profile-types.md).
3. Configure the profile basics: **name**, **description**, and **labels** for organization and catalog filtering
4. **Add Entitlements**: select the target application and the specific groups, roles, or permissions to include. You can select entitlements manually or use Access Profile Intelligence to suggest entitlements based on typical users.
5. Set **availability** for each entitlement:
   * **Available On Birthright**: access is automatically provisioned to matching users through Lifecycle Management policies (not requested through the catalog)
   * **Available On Request**: access is published as a requestable item in the Access Catalog. This is the setting for Access Requests.
6. Assign an **Access Request Policy**: select the policy created in Step 2 to govern approval workflows and access duration for this profile
7. **Assign ownership**: designate profile owners who can manage the profile and approve requests
8. **Configure catalog presentation**: use the Catalog Editor to add an icon, write a markdown description, and optionally mark the profile as recommended
9. **Enable** the profile and **publish** the current version

{% hint style="info" %}
**How suggestions are derived**: Access Profile Intelligence computes suggestions from the Access Graph, not from a language model. Veza returns the entitlements that the selected identities already hold, together with the percentage of those identities holding each one. Because the results describe access that already exists, review them before adding them to a profile: they can include access that is stale or broader than the role requires.
{% endhint %}

For detailed step-by-step instructions including the Catalog Editor, custom properties, and general guidelines, see [Managing Catalog Items](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md).

### Targeting catalog items to user cohorts

Different catalog items can be exposed to different groups of users. This is controlled through a combination of:

* **Access Profiles Settings**: in Access Request Settings, you can limit which profiles appear in the catalog by label or Access Profile Type (see [Catalog visibility controls](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#catalog-visibility-controls))
* **Catalog Definition visibility rules**: for advanced catalog definitions, SCIM filters can restrict visibility to specific user populations (see [Managing Catalog Definitions](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md))
* **Labels**: use labels consistently across profiles to control which cohorts see which catalog items (for example, label profiles "engineering" or "sales" and configure visibility to match)

For example, you might label engineering-related profiles with "engineering" and configure the catalog to show only profiles matching the user's department. As a result, requesters see the access options relevant to their department.

## Step 4: Create Catalog Definitions (optional)

Catalog Definitions provide additional control over how catalog items are fulfilled when requests are approved. While Access Profiles define the entitlements available for request, Catalog Definitions define the fulfillment mechanism and can add form fields, visibility rules, and catalog display customization.

Catalog Definitions are recommended when you need:

* **Application provisioning** with specific Sync Identity or Deprovision actions
* **ServiceNow ticket creation** for ITSM-based fulfillment
* **Custom REST API calls** for non-standard provisioning workflows
* **Fine-grained entitlement control** using allow/disallow lists
* **SCIM-based visibility rules** to target catalog items to specific user populations

To create a Catalog Definition:

1. Navigate to **Lifecycle Management** > **Catalog Definitions**
2. Select **Create Catalog Definition**
3. Select a type (Application, ServiceNow, or Send REST Payload)
4. Configure the definition's Details, Configuration, Visibility Rules, and Catalog Item Info
5. Associate it with a **Lifecycle Management Policy** and an **Access Request Policy**
6. Set the state to **Enabled**

For detailed configuration of each type, see [Managing Catalog Definitions](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md).

{% hint style="info" %}
**Catalog Definitions and Access Profiles**: The Access Catalog displays both Access Profiles (with Available On Request entitlements) and Catalog Definitions as requestable items. Catalog Definitions provide more control over the fulfillment process and catalog presentation, while Access Profiles offer a simpler configuration path. Both can coexist in the same catalog.
{% endhint %}

## Step 5: Verify catalog visibility

Log in to Veza Access Hub as different user roles to verify that Access Profiles appear as expected in the Catalog:

1. Log in as a **regular user** and navigate to **Access Hub** > **Catalog**
2. Verify that the configured profiles are visible and display the correct descriptions, icons, and entitlement details
3. Log in as a user in a **different department or role** to confirm that catalog targeting is working correctly. Users should only see profiles relevant to their cohort.
4. If profiles are not appearing as expected, check these conditions in order:
   * The user has a **resolved LCM policy identity**: the Catalog link only appears in the Access Hub sidebar when Veza can map the logged-in user to an LCM identity. This requires a configured identity source and a Lifecycle Management policy that has extracted the user.
   * **Access Request Settings** are enabled: `accessRequestSettings.enabled` must be true
   * The user is not on the **Deny Requestor List**
   * The profile is in **Enabled** state with a **published** version
   * The profile has **Available On Request** entitlements
   * The profile is permitted by the tenant-wide setting **Access Profiles available in Catalog and while requesting access**, which either allows all Access Profiles, limits the catalog to selected Access Profile labels, limits it to selected Access Profile Types, or allows none. See [Global requestable settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#global-requestable-settings).

For a detailed explanation of how visibility conditions interact, see the [Visibility Decision Flow](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#how-visibility-controls-interact) in Access Request Settings.

## Step 6: Test end-to-end

After completing the previous steps, validate that the Access Request Policies, Access Profiles, and visibility settings are correctly applied by performing an end-to-end test:

1. Log in as a regular user via SSO
2. Navigate to **Access Hub** > **Catalog**
3. Request access to a catalog item, providing a justification and selecting a duration
4. Log in as an approver via SSO
5. Navigate to **Access Hub** > **Catalog** > **Assigned Requests**
6. Review and approve the request
7. Verify that access is granted correctly in the target system

If the test request was processed successfully, your Access Requests configuration is complete.

{% hint style="warning" %}
**Common E2E test failures**:

* **Catalog link not visible**: Verify the Access Hub Identity Provider is set to LCM Identity mode and that the user has a resolved LCM identity (check `GET /api/private/lifecycle_management/identities:me`).
* **No catalog items visible**: Verify the Access Profile or Catalog Definition is Enabled, the version is Published, and the tenant-wide setting **Access Profiles available in Catalog and while requesting access** permits the profile, either through **Allow all Access Profiles** or through a label or type filter that matches it. See [Global requestable settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#global-requestable-settings).
* **Entitlement dropdown empty in request form**: For Catalog Definitions, verify the Lifecycle Management datasource extraction has completed. The entitlement list is populated from the target integration's LCM datasource.
* **Duration shows "Never Expires" when JIT is configured**: The requester must manually select a duration from the dropdown. If JIT duration is required by the policy and the requester submits with "Never Expires", the request fails.
* **Approval not routed to manager**: Beneficiary Manager approval requires the beneficiary's Lifecycle Management identity to carry a manager that resolves to another identity, and that manager to have a Veza user account. Not every identity source populates a manager that resolves. See [Beneficiary Manager approvals](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#beneficiary-manager-approvals).
* **Provisioning error after approval**: Verify the target integration has write permissions enabled and the Lifecycle Management datasource extraction is complete. For Catalog Definitions, confirm that the Assignee Entity Type matches the target system's user entity type.
* **Request completes but access is missing in one application**: Veza resolved no account for the beneficiary in that data source and skipped it. Check the request's Events tab for `No local user/account or synced identity found for datasource`, then see [Identity resolution](#identity-resolution).
  {% endhint %}

## Next steps

* **Expand the Catalog**: create additional [Access Profiles](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md) for different applications and user groups
* **Configure Notifications**: set up [email and Slack notifications](/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md) for request events
* **Train Users**: share the [Requesting Access](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md) guide with end users and the [Approving Requests](/4yItIzMvkpAvMVFAamTf/features/access-request/approve-access.md) guide with approvers
* **Monitor and Audit**: review the [Access request history](/4yItIzMvkpAvMVFAamTf/features/access-request/request-history.md) to track all access changes

## Related documentation

* [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md): feature overview and architecture
* [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md): global settings reference
* [Managing Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md): approval workflows and JIT access
* [Managing Catalog Items](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md): Access Profile catalog configuration
* [Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md): profile concepts and Lifecycle Management integration
* [Access Profile Types](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/access-profile-types.md): profile type configuration
* [Managing Catalog Definitions](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md): catalog fulfillment types
* [Dynamic Approvers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-approvers.md): runtime-resolved approval routing
* [Access Hub Configuration](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md): identity flow diagram and the per-system identity mapping configuration points
* [Global IdP Settings](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings.md): identity provider configuration
* [Single Sign-On Settings](/4yItIzMvkpAvMVFAamTf/administration/administration/sign-in-settings/saml.md): SAML SSO setup
* [User Roles and Permissions](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md): role capabilities
* [Lifecycle Management Integrations](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/integrations.md): target application setup


---

# 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.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/enable-access-requests.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.