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

# Settings

Configuration of global settings that define system-wide behaviors for Veza Access Requests.

Configure Access Request Settings to establish the approval permissions, catalog visibility, security controls, and notification behavior that apply across every access request in your tenant.

## Overview

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

* **Approvals**: Who is allowed to approve requests (administrators, Access Profile Owners, App Owners)
* **Access Profiles Settings**: Which Access Profiles appear in the Access Catalog for users to request
* **Deny Approver List** and **Deny Requestor List**: Which users are barred from approving or from requesting
* **Available Explanations** and **Reviewer Delegation List**: Standardized request explanations, and delegation of approval duties
* **Enforce SSO Login**: Which request actions record a Single Sign-On re-authentication requirement
* **Notifications**: Event-based notifications for stakeholders

Access Request Settings work with [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md) to create a flexible access governance framework. While Settings control *who can approve* and *what's visible in the catalog*, Policies define the actual *approval workflows* (who must approve and in what order) and *time limits* (JIT duration) for specific Access Profiles or Access Profile Types.

{% hint style="info" %}
**Settings versus Policies**: Access Request Settings are global, tenant-wide configurations that apply to all requests. Access Request Policies define specific approval workflows, JIT duration limits, and expiration behavior for individual Access Profiles or Access Profile Types. See [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md) for policy configuration.
{% endhint %}

For information about how these components integrate with the overall Access Requests system, see [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md).

## Platform integration

Access Request Settings work in conjunction with other Veza platform configuration to provide a complete access governance framework:

### Related platform configuration

Access Request Settings work alongside other platform components. For setup instructions, see [Set up Access Requests](/4yItIzMvkpAvMVFAamTf/features/access-request/enable-access-requests.md), which covers:

* **Global IdP Settings**: required for manager-based approval workflows. See [Global IdP Settings](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings.md).
* **Access Hub Configuration**: entity type visibility, page visibility, and identity mapping. See [Access Hub Configuration](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md).

### Configuration APIs

Access Request configuration can be managed through Veza's REST APIs for automation and bulk operations:

* Create and manage Access Profiles programmatically
* Configure Access Request Policies via API
* Update Access Request Settings
* Query request status and history

For API documentation, see [Veza API Reference](/4yItIzMvkpAvMVFAamTf/developers/api.md).

### Secondary global IdP

Organizations using multiple identity providers can configure a Secondary Global IdP to:

* Support users from different identity systems
* Enable manager relationships across identity providers
* Consolidate access governance for multi-IdP environments

See [Secondary Global IdP Configuration](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings.md) for setup instructions.

## Accessing the settings

To configure Access Request Settings:

1. Log in to Veza with administrative privileges
2. Navigate to **Lifecycle Management** > **Settings** > **Access Request Settings**

The settings page is organized into tabs for different categories of settings.

## Available settings

Access Request Settings are grouped into approval permissions, catalog visibility controls, advanced settings, and notification settings.

### Approval permissions

Three categories of user can hold approval permissions across the tenant: administrators, Access Profile Owners, and App Owners. All three share the same two settings, and each category is configured on its own tab. These settings define who **can** approve requests, not **how** approval workflows are structured.

| Setting                        | API property                | Description                                                                                                                  |
| ------------------------------ | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Allow approval on requests** | `allow_approval_on_request` | Lets the category act as an approver on the requests within its scope                                                        |
| **Grant without approval**     | `grant_without_approval`    | Lets a member of the category grant a request they submitted themselves, within the same scope, without an approval workflow |

{% hint style="info" %}
**UI versus API property names**: The Veza console labels these toggles **Allow approval on requests** and **Grant without approval**. The **API property** column gives the corresponding field names in the Access Request Settings API; the console does not display them. This documentation uses the UI labels unless referring to the API specifically.
{% endhint %}

{% hint style="info" %}
**Approval workflows**: These settings control approval *permissions*. The actual approval *workflows* (who must approve and in what order) are defined in Access Request Policies. See [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md) for workflow configuration.
{% endhint %}

#### Admin approval settings

These settings apply to every access request in the tenant, regardless of ownership.

Configuration steps:

1. Navigate to **Approvals** > **Admin Approval**
2. Toggle the settings for your organization
3. Select **Save**

#### Access Profile Owner approval settings

These settings apply to requests for the Access Profiles that the user owns.

Configuration steps:

1. Navigate to **Approvals** > **Access Profile Owner Approval**
2. Toggle the settings for your organization
3. Select **Save**

#### App Owner approval settings

These settings apply to requests for access that comes from the integrations that the user owns.

App Owner approval draws on the owner list recorded on the integration behind the requested access. Veza resolves that list from the requested Access Profile, through the profile's data sources, to the parent integration, then expands the integration's owner list, resolving any groups to their members. These are the same people that the console identifies as integration owners elsewhere; Access Requests holds no separate application-owner record. Resolution reads the integration's own owner list rather than the **Integration Owner** platform role, so assigning that role is not what makes a user an App Owner approver. See [Manage Integration Permissions](/4yItIzMvkpAvMVFAamTf/integrations/configuration/manage-integration-permissions.md).

This category is distinct from **Access Profile Owner**, which covers ownership of the catalog item rather than ownership of the integration behind it.

Configuration steps:

1. Navigate to **Approvals** > **App Owner Approval**
2. Toggle the settings for your organization
3. Select **Save**

## Catalog visibility controls

Multiple mechanisms determine which Access Profiles appear in the Access Catalog. Visibility is controlled through both global tenant-level settings and individual profile-level configuration.

### Global requestable settings

Configure which Access Profiles are available through the Access Hub Catalog at the tenant level:

| Setting                                     | Description                                                             | Configuration                                                                                        |
| ------------------------------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| **Allow all Access Profiles**               | All profiles in Enabled state are visible regardless of labels or types | No additional configuration needed                                                                   |
| **Limit to specific Access Profile labels** | Only profiles with specified labels appear in catalog                   | Enter comma-separated label values (for example, "engineering", "sales", "evergreen")                |
| **Limit to specific Access Profile types**  | Only profiles of specified types appear in catalog                      | Select from configured profile types (for example, Business Role, Profile, Application Entitlements) |
| **Not Allowed**                             | No profiles visible to any users                                        | Implicit when none of the above criteria are configured (not a discrete toggle)                      |

Configuration steps:

1. Navigate to **Access Profiles Settings**
2. Select the appropriate visibility option for your organization
3. For label or type filtering, specify the allowed values
4. Select **Save**

{% hint style="info" %}
**Label-Based Filtering**: In many environments, the "evergreen" label is commonly used to control catalog visibility. Applying it marks specific profiles as ready for self-service requests and keeps the rest hidden during development or testing.
{% endhint %}

### Profile state requirements

Access Profiles must be in the **Enabled** state to appear in the catalog, regardless of global settings.

{% hint style="info" %}
**UI versus API state names**: The Veza console shows profiles as **Enabled** or **Disabled**. The API uses more granular state names: `RUNNING` (= Enabled), `INITIAL`, `PENDING`, `PAUSED`, and `DRY_RUN` (all = Disabled). This documentation uses the UI labels unless referring to the API specifically.
{% endhint %}

**Profile States and Catalog Visibility**:

| State (UI / API)         | Visible in Catalog            | Notes                                 |
| ------------------------ | ----------------------------- | ------------------------------------- |
| **Enabled** (`RUNNING`)  | Yes (if other conditions met) | Active profiles available for request |
| **Disabled** (`PAUSED`)  | No                            | Profile temporarily suspended         |
| **Disabled** (`INITIAL`) | No                            | Profile not yet activated             |
| **Disabled** (`PENDING`) | No                            | Profile awaiting activation           |
| **Disabled** (`DRY_RUN`) | No                            | Profile in testing mode only          |

To activate a profile for catalog visibility:

1. Navigate to **Access Profiles** > **Profiles**
2. Edit the Access Profile
3. Set state to **Enabled**
4. Save the profile

{% hint style="warning" %}
**State Requirement**: Even if a profile matches label or type filters, it does not appear in the catalog unless it's in Enabled state. This is a common reason why profiles don't show in the catalog after configuration.
{% endhint %}

### Version publishing

Access Profiles carry a version number, so you can revise a profile without disrupting an active configuration. A profile records a current version and, while edits are in progress, a draft version.

**Version states**: `DRAFT`, `PUBLISHED`, and `RETIRED`.

{% hint style="info" %}
**Version state does not control catalog visibility.** Veza decides whether a profile appears in the Access Catalog from the profile state (**Enabled**), the tenant-wide requestable setting, and the requester's access to the underlying data source. It does not evaluate the version state. See [Catalog visibility controls](#catalog-visibility-controls).
{% endhint %}

### How visibility controls interact

Multiple visibility conditions work together to determine if a profile appears in the catalog. The checks happen in sequence:

**Visibility Decision Flow**:

1. **Global Access Requests Enabled?**
   * If NO → Entire catalog hidden from all users
   * If YES → Continue to profile checks
2. **Profile Enabled?**
   * If NO → Profile hidden
   * If YES → Continue
3. **Profile Version is PUBLISHED?**
   * If NO → Profile hidden
   * If YES → Continue to requestable settings
4. **Profile Matches Requestable Settings?** (OR logic - any match makes it visible)
   * Global setting is "Allow all Access Profiles"? → **Profile visible** ✓
   * Profile labels match `allow_with_labels`? → **Profile visible** ✓
   * Profile type matches `allow_from_types`? → **Profile visible** ✓
   * None of the above? → Profile hidden

The requestable settings use OR logic: a profile is visible if it matches any of the criteria (allow all, a matching label, or a matching type).

### Computed requestable field

Access Requests automatically computes a `requestable` boolean field on each Access Profile based on the visibility decision flow above.

When you change global requestable settings:

1. Veza evaluates all Access Profiles against the new criteria
2. Updates the `requestable` field for each profile (true or false)
3. The catalog displays only profiles where `requestable = true`

This computed field improves catalog performance - visibility doesn't need to be re-evaluated on every page load.

### Profile-level display settings

Individual Access Profiles have customizable catalog display settings that control **how** they appear in the Access Catalog (but not **whether** they appear). These settings are configured using the Catalog Editor, which allows administrators to:

* **Customize visual presentation**: Upload custom icons and write markdown-formatted descriptions
* **Provide context to requesters**: Explain the profile's purpose, target audience, and included entitlements
* **Allow to be recommended**: Permit the profile to appear in Access Catalog recommendations

The Catalog Editor provides a live preview of how the profile appears to end users in the Access Hub, helping administrators create clear catalog entries.

For detailed instructions on using the Catalog Editor and configuring profile display settings, see [Managing Access Profiles](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md).

### Troubleshooting catalog visibility

If an Access Profile isn't appearing in the catalog, check these conditions in order:

| Check                                 | Location                | Fix                                      |
| ------------------------------------- | ----------------------- | ---------------------------------------- |
| Access Requests enabled?              | Access Request Settings | Turn on the **Enable Requests** toggle   |
| Profile Enabled?                      | Access Profile settings | Change profile state to Enabled          |
| Profile version PUBLISHED?            | Access Profile versions | Publish the current draft version        |
| Profile matches requestable settings? | Access Request Settings | Verify labels, types, or use "Allow all" |

{% hint style="info" %}
**Quick Test**: Temporarily set global requestable settings to "Allow all Access Profiles". If the profile still doesn't appear, the issue is likely with profile state or version publishing, not the requestable settings.
{% endhint %}

## Advanced settings

The Access Request Settings page includes advanced configuration options for enhanced security, delegation, and access control.

### Available explanations

Configure predefined explanation options that requesters can select when submitting access requests. Predefined explanations can help standardize request justifications, speed up request submissions, and improve audit trails.

To manage available explanations:

1. Navigate to the **Available Explanations** section in Access Request Settings
2. Use the dropdown to add standard explanation options (for example, "Project work", "Temporary coverage", "Role change")
3. Remove explanations that are no longer relevant using the remove button
4. Select **Save**

### Dynamic Approvers

Dynamic Approvers resolve the approvers for an approval step when a request is submitted, rather than naming them in the policy. A Dynamic Approver is a Lifecycle Management transformer pipeline that runs over the request's attributes and outputs approver email addresses. Every Lifecycle Management transformer function is available to these expressions except the thirteen listed below.

**Functions that a Dynamic Approver cannot use**

`DATE_FORMAT`, `DATE_ADJUST`, `DATE_ADJUST_DAY`, `NOW`, `ASSUME_TIME_ZONE`, `UTC_TO_TIME_ZONE`, `RANDOM_STRING_GENERATOR`, `RANDOM_NUMBER_GENERATOR`, `RANDOM_ALPHANUMERIC_GENERATOR`, `RANDOM_INTEGER`, `UUID_GENERATOR`, `NEXT_NUMBER`, and `COUNTRY_CODE_ISO3166`.

Most of these produce a different result each time they run, whether from randomness, the current clock, or a stored counter. Approver resolution has to be reproducible, so those functions are rejected. A custom function is rejected as well if its expression uses one of them.

Veza validates the pipeline when you save the Dynamic Approver, not when a request resolves it.

To create or edit one:

1. Scroll to the **Dynamic Approvers** section of Access Request Settings
2. Add the transformer steps that produce the approver email addresses
3. Select **Test Configuration** to confirm that the pipeline resolves to the approvers you expect
4. Save the Dynamic Approver, then reference it from a **Dynamic** approval step in an Access Request Policy

For the available attributes, transformer syntax, lookup tables, and the full procedure, see [Dynamic Approvers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-approvers.md). For the policy side, see [Manage Access Request policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#approver-settings). For how a resolved approver list behaves after a request exists, see [How dynamic approvers resolve](/4yItIzMvkpAvMVFAamTf/features/access-request/approve-access.md#how-dynamic-approvers-resolve).

### Reviewer delegation

Configure delegation rules that let another user approve alongside an approver. This is useful for VIPs, during out-of-office periods, organizational changes, or when distributing approval workload.

To add a delegation:

1. Select **Add Delegation** in the Reviewer Delegation List section
2. Select the delegator (original approver)
3. Select the delegate
4. Save the delegation

Delegation is additive. The delegate is added to the request's approver set alongside the original approver, who keeps the ability to approve. Either can act on the request.

{% hint style="info" %}
**Per-user delegations**: Approvers can manage their own delegations, including an optional scheduled window and a note, from the **My Delegations** page in Access Hub. Administrators can manage any user's delegations from the **Access Request Delegations** tab in Lifecycle Management settings. Delegations configured there and in the Reviewer Delegation List both apply. See [Delegate access request approvals](/4yItIzMvkpAvMVFAamTf/features/access-request/my-delegations.md).
{% endhint %}

{% hint style="warning" %}
**Delegation Security**: A delegate approves with the same authority as the approver who delegated to them. Authorize delegations deliberately and review them on a regular schedule.
{% endhint %}

Both the delegator and the delegate must have Veza platform user accounts, created via SSO login. Delegation references Veza user IDs, not LCM identity IDs. If a user has an LCM identity but has not logged in to Veza, they cannot participate in a delegation.

**Delegation troubleshooting:**

| Issue                                                             | Solution                                                                                                                           |
| ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| User doesn't appear in the delegate selector                      | The user has not logged into Veza via SSO. Have them log in once via SSO before configuring delegation.                            |
| The original approver is still asked to approve                   | This is expected. A delegate is added alongside the original approver rather than replacing them, so both can act on the request.  |
| User appears in LCM identities but not in the delegation selector | An LCM identity and a Veza user account are separate records. The user needs at least one SSO login to create a Veza user account. |

### Request on behalf of others

The **Request on behalf of others** setting chooses who can submit access requests for other identities. It offers two options:

* **Managers only (self and direct reports)**: a user can request access for themselves and for their direct reports. This is the default.
* **Everyone (request on behalf of anyone)**: a user can request access for any identity in the tenant.

The setting scopes the **Request for** picker on the request form, and it also widens what the **Requests** page shows. Under **Everyone**, a user who looks up a particular beneficiary sees that beneficiary's requests whatever their own relationship to them, including requests somebody else created. See [Request visibility](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md#request-visibility).

Under **Everyone** it also changes who is copied on notifications: the requester's managers are dropped from the Creator recipient copy, because a requester acting for an unrelated beneficiary has no reporting relationship to the access being requested. See [Recipient configuration](/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md#recipient-configuration).

### Deny approver list

Exclude specific users from approver assignment, even if they would otherwise qualify based on their role, ownership, or manager relationship.

To configure the deny approver list:

1. Scroll to the **Deny Approver List** section
2. Enter or select users who should not be allowed to approve requests
3. Select **Save**

Use cases for denying approvers include excluding individuals with conflicts of interest, omitting some reviewers during onboarding or offboarding, and preventing approval loops in complex organizational structures.

### Deny requestor list

Block specific users from creating access requests. Users on this list cannot browse the catalog or submit requests through the Access Hub.

To configure the deny requestor list:

1. Scroll to the **Deny Requestor List** section
2. Enter or select users who should not be allowed to make requests
3. Select **Save**

{% hint style="info" %}
Users on the deny requestor list can still have access granted to them by administrators or through other automated processes. The setting applies only to requests they submit themselves.
{% endhint %}

Administrators may use these options to block access requests from service accounts, enforce restrictions during an incident, or meet compliance requirements for certain user types.

### Enforce SSO login

The **Enforce SSO Login** setting records which access request actions should require Single Sign-On re-authentication.

{% hint style="warning" %}
**Known limitation**: Veza saves and returns this setting but does not currently enforce it. Selecting actions here does not require re-authentication and does not restrict who can perform them. Do not rely on it as a security control.
{% endhint %}

To configure SSO enforcement:

1. Scroll to the **Enforce SSO Login** section
2. Specify which actions require SSO re-authentication
3. Select **Save**

Select one or more request actions from the **Actions that require SSO** list. The list includes the available access request actions, such as Approve, Reject, Cancel, Request More Information, Re-request, and Revoke Access.

## Notification settings

Configure notifications to inform stakeholders about access request events using Veza Actions for delivery through email and Slack.

Access Request notifications can be triggered by the following events:

| Event Type        | API Value                          | Description                             |
| ----------------- | ---------------------------------- | --------------------------------------- |
| Request Created   | `ACCESS_REQUEST_CREATED`           | A new request is submitted              |
| Action Run        | `ACCESS_REQUEST_ACTION_RUN`        | Access plan execution begins            |
| Request Completed | `ACCESS_REQUEST_COMPLETED`         | Request is successfully fulfilled       |
| Request Failed    | `ACCESS_REQUEST_FAILED`            | Request execution fails                 |
| State Changed     | `ACCESS_REQUEST_STATE_CHANGED`     | Request transitions between states      |
| Approver Assigned | `ACCESS_REQUEST_APPROVER_ASSIGNED` | New approvers are assigned to a request |

To configure notifications:

1. **For Slack notifications only**: Create Veza Actions for Slack Webhook or Slack App
   * See [Veza Actions](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications.md) for setup instructions
   * Email notifications do not require preconfigured actions
2. Navigate to **Lifecycle Management** > **Settings** > **Access Request Settings**
3. In the **Notifications** section, select **Create Notification**
4. Select the event type and notification method:
   * **Email**: Select recipients directly (no action required)
   * **Slack Webhook** or **Slack App**: Choose a preconfigured Veza Action. These are two separate options; **Slack App** appears only when the Slack app integration is enabled for your tenant
5. Save your configuration

**Email recipient options**: When configuring email notifications, the following recipient types are available:

| Recipient        | Description                                                                                                      |
| ---------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Approvers**    | All assigned approvers for the request                                                                           |
| **Creator**      | The user who submitted the request                                                                               |
| **Beneficiary**  | The user who receives the access                                                                                 |
| **Watchers**     | Users added as [watchers](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md) on the request |
| **Other emails** | Manually specified email addresses                                                                               |

For complete information about notification events, email templates, placeholders, recipient options, and general guidelines, see [Access Request Notifications](/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md).

## Settings scope

Unlike Access Request Policies, which are applied per Access Profile or Access Profile Types, Access Request Settings apply globally (tenant-wide).

## Settings precedence

When determining effective configuration, Veza applies settings in this order:

1. **System-wide Access Request Settings** (this document)
   * Global approval permissions
   * Catalog visibility filters
   * Security controls (SSO, deny lists)
2. **Access Profile Type Settings**
   * Applied to all profiles of this type
3. **Individual Access Profile Settings**
   * Applied to specific profiles
4. **Access Request Policies** (see [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md))
   * Approval workflows
   * JIT duration limits
   * Expiration behavior

## General guidelines

When configuring Access Request Settings:

* **Start Restrictive**: Begin with more restrictive settings and loosen as needed
* **Clear ownership**: Assign explicit owners to Access Profiles so that approval workflows can route to them
* **Consistent Labeling**: Develop a consistent labeling strategy for catalog visibility
* **Regular Review**: Periodically review settings as your organization's needs evolve
* **Use Policies for Workflows**: Define approval workflows and time limits in Access Request Policies, not Settings

## Verifying settings

After configuring Access Request Settings:

1. Navigate to the Access Requests Catalog as a regular user
2. Verify that the expected Access Profiles are visible
3. Test the request process and confirm that approvals route correctly
4. Check notification delivery for various request events

## Troubleshooting

Common issues with Access Request Settings:

| Issue                                    | Possible Solution                                                                                                                                                                                                                                                                                                                      |
| ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Access Profiles not appearing in catalog | Verify label configuration and profile availability settings                                                                                                                                                                                                                                                                           |
| Approvals not routing correctly          | Check admin and owner approval settings                                                                                                                                                                                                                                                                                                |
| Notifications not being sent             | Verify notification settings and templates                                                                                                                                                                                                                                                                                             |
| JIT access not expiring correctly        | Check JIT policy configuration in Access Request Policies. For a Jira-backed request, also confirm that an administrator resolved the grant issue: the expiry clock does not start until then. See [Ticket creation with Jira](/4yItIzMvkpAvMVFAamTf/features/access-request/configure-itsm-integration.md#ticket-creation-with-jira). |

If issues persist, check Veza's logs for specific error messages and contact Veza Support.

## Related documentation

* [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md): Core concepts and workflows
* [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md): Detailed policy configuration
* [Set up Access Requests](/4yItIzMvkpAvMVFAamTf/features/access-request/enable-access-requests.md): Initial configuration steps
* [Requesting and Managing Your Access](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md): End-user guide to requesting and managing access
* [Managing Request Watchers](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md): How users can add watchers to track requests


---

# 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/settings.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.