> 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/manage-policies.md). # Manage Access Request policies Create, configure, and manage Access Request Policies that control approval workflows and access duration. Create, configure, and manage Access Request Policies in Veza Access Requests. Policies define approval workflows (when required), how approvals behave when approvers do not respond, and the duration of access granted for a given access request. ## Overview Access Request Policies provide granular control over how access requests are processed for approval as well as the duration of access granted. They allow administrators to place additional conditions on access requests associated with a policy, such as: * Implement multi-step approval processes for specific resources, including identifying the designated approvers at each approval level * Set rules for handling non-responsive reviewers * Set rules for how long a pending access request is maintained before it expires * Set time limits - access duration - for granted access * Automate approvals for low-risk resources Access Request Policies are managed centrally under **Lifecycle Management** > **Settings** > **Access Request Policies**. Access Request Policies can be associated with an Access Profile Type - all Access Profiles derived from that type inherit the Access Request Policy by default. Alternatively, individual Access Profiles can be associated with an Access Request Policy; this overrides the inherited Access Request Policy set at the Access Profile Type level. ## Policy application and precedence Access Request Policies can be applied at two levels in your organization's access governance hierarchy: ### Access Profile Type level A policy assigned to an Access Profile Type applies to all Access Profiles of that type. This provides consistent approval workflows and access duration settings across similar access types. For example, you might apply a strict policy to all "High-Security Applications" profiles, ensuring they all require multi-step approval. ### Access Profile level A policy assigned to an individual Access Profile overrides any Type-level policy for that specific profile. Use a profile-level policy to customize the workflow for one application or resource while the Type-level policy continues to govern the rest. ### Precedence hierarchy When determining which policy applies to an access request, Veza follows this order: 1. **Profile-level policy** (highest priority): a policy assigned directly to an Access Profile 2. **Type-level policy** (fallback): a policy assigned to the Access Profile Type If a profile has its own policy, the type-level policy is ignored for that profile. If no policy is assigned at either level, the request proceeds without policy-specific approval requirements (subject to [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md)). For example: * Set a standard 7-day duration at the Type level for "Standard Applications" * Override specific profiles like "Production Database Access" with a stricter 4-hour duration **General guidelines for policy management:** * **Start at the Type Level**: Configure a default Access Request Policy at the Access Profile Type level first, then create profile-specific policies for exceptions. There is no global Access Request Policy. The highest level of application is the Access Profile Type. * **Group Similar Catalog Items**: Apply the same policy to resources with similar approval workflow and access duration requirements. * **Limit Policy Proliferation**: Focus on a minimal set of Access Request Policies. Many policies can become difficult to manage over time. * **Regular Review**: Confirm policies continue to align with organizational needs. * **Clear Naming**: Use descriptive names that indicate the policy's purpose and behavior (for example, "High-Security 24h Manager+Admin" or "Standard 7-Day Auto-Approve"). ## Accessing policy management To manage Access Request Policies in Veza: 1. Navigate to the **Lifecycle Management** section 2. Select **Settings** 3. Choose the **Access Request Policies** tab This tab shows all policies, including the name, state, description, and an indication if the policy is currently in use (currently applied to one or more access profiles). ## Creating a new policy To create a new Access Request Policy: 1. In the **Access Request Policies** tab, select **New Access Request Policy** 2. Enter a name and description for the policy 3. Configure **Expiration Policy** and **Access Duration** (described below) 4. Configure **Approver Settings** 5. Save the policy Each Access Request Policy consists of three main components: ### Access duration and time-limited access Toggle Enable Duration Settings to configure access duration limits for the policy. Access Request Policies control both approval workflows AND access duration. When duration limits are configured, approved access automatically expires after the specified time - this is known as Just-in-Time (JIT) access or time-limited access. Access Duration Options: * **Never expires**: When enabled, access granted is permanent until explicitly revoked * **Min duration**: Minimum time that access is valid for (specify in hours or days) * **Max duration**: Maximum time that access is valid for (specify in hours or days) * **Allow requester to adjust access duration (within range)**: When enabled, the requester can choose a duration within the min/max range when submitting a request * **Allow approver to adjust access duration (within range)**: When enabled, the approver can adjust the requested duration when approving (within the min/max range) ### Expiration policy The expiration policy defines what happens when a pending access request exceeds the configured time limit without being acted upon. Toggle **Enable Expiration Policy** to configure, then set the expiration time (in days or minutes) and the action taken on expiration: | Action on Expiration | Description | | -------------------- | ------------------------------------------------- | | **Reject** (default) | Automatically reject the request when it expires | | **Approve** | Automatically approve the request when it expires | | **Escalate** | Escalate the request to additional approvers | When **Escalate** is selected, you can configure escalation targets: | Escalation Target | Description | | -------------------------------- | ------------------------------------------------------------------------------ | | **Admin** | Escalate to system administrators | | **App Owner** | Escalate to the owners recorded on the integration behind the requested access | | **Access Profile Owner** | Escalate to the owners of the requested Access Profile | | **Approver's Manager (Level 1)** | Escalate to the direct manager of the current approver | | **Approver's Manager (Level 2)** | Escalate to the second-level manager of the current approver | | **Specific Users** | Escalate to named individual users | | **Specific Groups** | Escalate to named Veza Groups | ### Approver settings Defines who must approve requests and in what order. For more information about approval workflows and approver categories, see [Approving Access Requests](/4yItIzMvkpAvMVFAamTf/features/access-request/approve-access.md). To allow immediate access on request: 1. In the policy creation sidebar, scroll down to **Approver Settings** 2. Toggle **Grant Without Approval** Requests can require one or more levels of approval before access is granted. For a step to be completed: 1) all required approval categories must be satisfied, and 2) at least one of the specific approvers (if any) must approve. To enable multi-step approvals: 1. In the policy creation sidebar, scroll down to **Approver Settings** 2. Toggle **Enable Approval Settings** 3. Select **Add Step** to add an approval step 4. For each step, configure: * **Categories**: select one or more approver categories (Admin, Access Profile Owner, Beneficiary Manager, App Owner, or Dynamic). For a description of each category, see [Approver Categories](/4yItIzMvkpAvMVFAamTf/features/access-request/approve-access.md#approver-categories). * **Other Approvers (Users)**: individually named users who must approve * **Other Approvers (Groups)**: Veza Groups whose members can approve. When a group is assigned, **any single member** of the group can approve on behalf of the group; all members do not need to approve individually. 5. Select **Add Step** to add additional sequential steps, or **Remove** to delete a step 6. Select **Create** to save the access request policy After saving the policy, you can start, edit, or delete it on the **Lifecycle Management Settings** > **Access Request Policies** tab. {% hint style="info" %} **Dynamic Approvers**: When adding an approval step, you can select the **Dynamic** category to resolve approvers at request time using a transformer pipeline. Dynamic approvers are configured under **Lifecycle Management** > **Settings** > **Access Request Settings**. See [Dynamic Approvers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-approvers.md) for details. {% endhint %} Each approval step can be configured to skip automatically when all assigned approvers are inactive, so a request does not stall when its approvers are no longer active in the organization. ### Beneficiary Manager approvals The **Beneficiary Manager** category resolves to the manager of the identity that the request is for. Two conditions must both hold when the step becomes the current step: 1. Veza knows who the beneficiary's manager is, from the identity source that supplied the beneficiary's identity. 2. That manager has a Veza user account. The manager's identity is matched to the account by email address, without regard to case. Manager information is derived automatically while identities are processed. It is a built-in field, so there is nothing to map in the policy and nothing to configure on the integration. If the identity source carries no manager for a person, the field stays empty. There is no placeholder value and no error. The same requirement applies to secondary sources of identity, not only to the primary source. **Identity sources that resolve a manager** * **Okta** and **Azure / Entra ID** resolve managers to Veza identities automatically. * **Workday** writes manager references into the same namespace as worker identities, so they resolve. If extracted-PII redaction is enabled for the integration, manager values are removed and do not resolve. * **OAA HRIS connectors** resolve a manager under the condition described below. **OAA HRIS connectors** The HRIS template rewrites each manager reference into an employee identity with the same formula that builds the employee's own identity. Resolution succeeds only when the connector supplied the manager's own employee record identifier. It fails when the connector supplied a different identifier, such as a login name or a separate user ID. * Confirmed to resolve: ADP Workforce Now, Personio, Coupa Contingent Workforce, UKG Pro, CSV Upload, and Database HRIS. * Expected to resolve, but not confirmed end to end: HiBob, Beeline, and BambooHR. * Confirm on your tenant before relying on Beneficiary Manager: SAP SuccessFactors, Oracle HCM, and Ivanti Neurons. SAP SuccessFactors is the least likely to resolve, because employee identities are built from one identifier while the manager reference carries a different one. Oracle HCM and Ivanti Neurons resolve only if the column or link that holds the manager carries the same identifier used for the employee record. **Identity sources that do not resolve a manager** * **Active Directory**. Active Directory has a source of identity workflow and does populate a manager reference, but the value is the manager's distinguished name rather than the entity ID of the manager's identity in Veza, so the value does not match. * **ServiceNow**. The user record carries the manager as a display name rather than as an identifier, so it cannot be matched to an identity. The manager property on ServiceNow group records is a separate property and is not used for approvals. * **OAA Custom IdP connectors**. The Custom IdP template writes a single manager reference under a property that identity processing does not read. The generic LDAP connector gathers no manager information at all. For these sources, use a different approver category, such as a named approver or a dynamically resolved approver, instead of Beneficiary Manager. **When no manager resolves** If Beneficiary Manager is the only approver source on the step and no manager resolves, the request moves to **Conflict Pending** instead of waiting indefinitely. The request was created and is recoverable. An administrator can reassign or cancel it, and the requester can submit it again. Two situations produce this state, and the remedy differs: * A manager is identified but has no Veza user account. Create the account. Accounts are commonly created on the manager's first SSO login. * The beneficiary has no manager in the identity source. Set the manager in the source system. If the step names any other approver source, such as a second category or a named user or group, that source satisfies the step and the unresolved manager adds nobody. If a step names two or more categories and none of them resolves to anyone, the request also moves to Conflict Pending. These checks run when a request is created, when it is requested again, and when it advances onto a new step, so a dead end on a later step is caught when the request reaches it. {% hint style="info" %} A tenant setting can re-evaluate requests in Conflict Pending on a schedule and return them to Waiting For Approval once an eligible approver exists. Go to **Lifecycle Management** > **Settings** > **Access Request Settings**, find **Retry blocked requests**, and turn on **Retry blocked requests automatically**. The setting is turned off by default. **Check every** sets the number of minutes between checks, from 1 to 1440, and falls back to 10 minutes when left empty. Turn it on if you would rather have requests recover on their own than be rescued by an administrator, for example when managers routinely receive their Veza account on first SSO login shortly after a request is submitted. {% endhint %} To troubleshoot a step that resolves to no approver, check the beneficiary's Lifecycle Management identity. Its `manager_entity_ids` field must hold the entity ID of another Lifecycle Management identity, not a raw source reference such as a distinguished name or a display name. A field that is populated but holds an unmatchable value yields no approver, exactly as an empty field does. ## Editing an existing policy Editing an Access Request policy in the Veza console updates the live policy in place. There is no draft stage in the console: when you save, the change applies to access requests submitted from that point onward. Requests already awaiting approval continue under the configuration they were evaluated against when they were submitted. {% hint style="warning" %} Because an edit takes effect as soon as you save it, plan changes to a policy that is already applied to Access Profiles or Access Profile Types. To stage a change, disable the policy, edit it, then enable it again. {% endhint %} Access Request policies do have an underlying version model. Each policy can have one published version and one draft version at a time, with earlier versions retired automatically as new ones are published, and the Veza API can create, publish, and delete versions. These operations are available **only through the API**: the console does not expose draft creation, publishing, or version history for Access Request policies. Draft-and-publish workflows in the console apply to Access Profiles and to Lifecycle Management provisioning policies, which are separate objects with their own settings. {% hint style="warning" %} Do not enable draft mode for Access Request policies through the API. The console is not built to edit a policy that has a draft as its current version, and enabling it blocks editing of Access Request policies in the console. {% endhint %} {% hint style="info" %} **Testing a policy before it applies**: Access Request policies do not support dry run. Dry run applies to Lifecycle Management provisioning policies and to Access Profiles. Within Access Requests, you can test how a **Dynamic** approver resolves: select **Test Configuration** on a dynamic approver under **Lifecycle Management** > **Settings** > **Access Request Settings** and choose an Access Profile or catalog definition to resolve it against. This validates approver resolution only, not the rest of the policy. {% endhint %} ### Initial state of new policies A tenant-wide setting controls the state that newly created Access Request policies start in: | Value | Description | | ------------------------------ | ------------------------------------------------------------------------------ | | `DEFAULT` | System default behavior (equivalent to `STATE_INITIAL`) | | `STATE_INITIAL` | Policy starts in Initial state and requires manual activation | | `STATE_RUNNING` | Policy starts in Running state and is immediately active | | `STATE_INITIAL_START_BY_ADMIN` | Policy starts in Initial state, and activation is restricted to administrators | This setting applies to all Access Request policies in the tenant, not to individual policies. Like draft mode, it is available through the Veza API only; the console does not expose a control for it. Changing it does not affect policies that already exist. ## Policy states In the Veza console, Access Request Policies display one of two states: | UI Label | Description | Action to Change | | ------------ | ------------------------------------------------- | ------------------------------------------ | | **Enabled** | Policy is active and applied to incoming requests | Select **Disable** in the row actions menu | | **Disabled** | Policy is inactive and not applied | Select **Enable** in the row actions menu | New policies start as **Disabled** by default. Enable a policy after completing all configuration (approval steps, duration settings, expiration rules). {% hint style="info" %} **Row actions**: Each policy in the list table has an actions menu with **Edit**, **Enable** or **Disable** (toggle), and **Delete**. **API states**: The Veza API represents policy state with an enumeration shared across Lifecycle Management objects, so API consumers may encounter more values than the console shows: `Initial`, `Running`, `Paused`, `DryRun`, and `Pending`. For an Access Request policy, only `Running` causes the policy to be applied to incoming requests; every other value leaves it inactive. In particular, `DryRun` is not a test mode for Access Request policies — a policy in that state simply does not apply. The console surfaces this state as **Enabled** or **Disabled**. {% endhint %} ## Applying policies to resources After creating a policy, you need to assign it to Access Profile Types, individual Access Profiles, or Catalog Definitions for it to take effect. ### Applying to an Access Profile Type Assigning a policy to an Access Profile Type establishes a default policy for all profiles of that type. This is the recommended starting point: it applies consistent governance across similar access types without configuring each profile individually. 1. Navigate to **Access Profiles** > **Profile Types** 2. Select the Access Profile Type (for example, "Application Entitlements", "Business Role") 3. In the **Access Request Policy** section, select the policy to apply 4. Save the changes All existing and future Access Profiles of this type inherit the policy unless they have their own profile-level override. ### Applying to an individual Access Profile Assigning a policy directly to an Access Profile overrides any type-level policy for that specific profile. Use this for exceptions, such as a production database profile that requires stricter approval than other profiles of the same type. 1. Navigate to **Access Profiles** > **Profiles** 2. Select the Access Profile you want to modify 3. Select **Edit** 4. In the **Access Request Policy** section, select the policy to apply 5. Save the changes {% hint style="info" %} **Type versus Profile**: When both a type-level and profile-level policy exist, the profile-level policy takes priority. The type-level policy is only used as a fallback for profiles that don't have their own policy assigned. {% endhint %} For more information about working with Access Profiles, see [Managing Catalog Items](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md). ## Example policy configurations ### High-security resources For resources requiring strict control: * Multi-step approval process (for example, manager approval followed by security team approval) * Limited access duration (for example, maximum 24 hours) * No auto-approval ### Standard resources For everyday resources: * Single-step approval by resource owner * Standard access duration (for example, up to 7 days) * Allow requesters to specify duration ### Low-risk resources For non-sensitive resources: * Auto-approval for authenticated users * Longer access duration (for example, up to 30 days) * Allow approvers to modify the requested duration ## Related documentation * [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md): Core concepts, lifecycle, and terminology * [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md): System-wide settings for Access Requests * [Managing Access Profiles](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md): Configuring Access Profiles * [Setting Up Access Requests](/4yItIzMvkpAvMVFAamTf/features/access-request/enable-access-requests.md): Initial configuration steps --- # 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/manage-policies.md?ask=&goal= ``` `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.