> 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/lifecycle-management/profiles/dynamic-approvers.md).

# Dynamic Approvers

Automatically determine who should approve an access request based on runtime context, access profile metadata, and lookup tables.

Dynamic Approvers is an Access Requests feature that lets Veza automatically determine who should approve an access request based on runtime context, access profile metadata, and external data.

Instead of assigning static approvers in a policy, you will configure a **transformer pipeline** that processes request attributes, access profile properties, and lookup tables to compute approver email addresses when the request is submitted.

Use Dynamic Approvers when approval routing will depend on metadata that can vary per request. For example, this can enable workflows in which Access Profiles assigned a specific cost center are routed to the appropriate approver group, or to assign managers based on department code.

### How it works

When an access request is submitted, Veza evaluates any policy steps configured with a Dynamic Approver:

1. Veza considers the name of the Access Profile or Catalog Definition being requested, and any custom properties set on that profile.
2. Each transformer step in the Dynamic Approver pipeline runs in sequence, processing the available attributes to produce an intermediate or final output.
3. The final transformer step must output one or more approver email addresses.
4. Veza assigns those email addresses as approvers for that policy step.

### Available attributes

The following attributes are available as inputs to transformer expressions:

| Attribute                              | Type   | Description                                         |
| -------------------------------------- | ------ | --------------------------------------------------- |
| `access_profile_name`                  | String | Name of the Access Profile being requested          |
| `catalog_definition_name`              | String | Name of the Catalog Definition being requested      |
| `last_output`                          | String | Output from the previous transformer step           |
| `access_profile_properties.<name>`     | String | Custom property value set on the Access Profile     |
| `catalog_definition_properties.<name>` | String | Custom property value set on the Catalog Definition |

Custom property attributes (`access_profile_properties.*` and `catalog_definition_properties.*`) are populated from the custom attribute definitions configured in [Access Profiles Settings](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md#defining-custom-attribute-schemas). The attribute names available in the transformer editor reflect the definitions currently configured in your tenant.

### Transformer expressions

Transformer expressions use the same syntax as Lifecycle Management [attribute transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.md): `{attribute}` for a direct reference, or `{attribute | FUNCTION, arguments}` to apply a function.

The most common function for Dynamic Approvers is `LOOKUP`, which resolves a value by looking it up in a [Lookup Table](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/lookup-tables.md). Lookup tables are CSV-based reference tables that map values between systems — for example, mapping department codes to approver email addresses. They are uploaded and managed within Lifecycle Management policy configurations.

The LOOKUP syntax is: `{value | LOOKUP, "table_name", "match_column", "return_column"}`

For example:

```
{access_profile_properties.department | LOOKUP, "dept_approvers", "dept_code", "approver_email"}
```

This takes the `department` custom property value from the Access Profile, looks it up in the `dept_approvers` lookup table by matching the `dept_code` column, and returns the corresponding `approver_email` value. See [Lookup Tables](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/lookup-tables.md) for details on creating and managing lookup tables.

You can chain multiple transformer steps. Use `{last_output}` in a subsequent step to reference the output of the previous step.

### Creating a Dynamic Approver

1. Go to **Lifecycle Management** > **Settings**.
2. Select the **Access Request Settings** tab.
3. Scroll to the **Dynamic Approvers** section and click **Create Approver**.
4. Enter a **Name** and optional **Description**.
5. Under **Transformer Steps**, click **Add Transformer Step** to add one or more steps:
   * Enter a formatter expression using the [available attributes](#available-attributes).
   * Set the **Output Type**:
     * **String** — the step produces a single value (e.g., one email address or an intermediate string).
     * **String List** — the step produces a comma-separated list of values (e.g., multiple email addresses from a LOOKUP that returns multiple rows).
6. Click **Create** to save.

{% hint style="info" %}
The final transformer step determines the approver emails. Intermediate steps can use **String List** output to return multiple values, which are then accessible via `{last_output}` in the next step.
{% endhint %}

#### Example: Two-step pipeline

This example resolves a department code to approver usernames via a lookup table, then appends a domain to produce email addresses.

**Step 1 — Look up approver usernames from department code**

```
{access_profile_properties.department | LOOKUP, "dept_approvers", "dept_code", "approver_usernames"}
```

Output Type: **String List**

**Step 2 — Convert usernames to email addresses**

```
{last_output}@company.com
```

Output Type: **String**

### Testing a Dynamic Approver

Before linking a Dynamic Approver to a policy, use the built-in test configuration to verify it resolves to the expected approver emails.

1. In the **Create** or **Edit Dynamic Approver** dialog, scroll to **Test Configuration**.
2. Under **Test Source**, select **Access Profile** or **Catalog Definition**, then choose a specific record to test with.
3. Optionally, add **Policy Properties** — key-value pairs that simulate additional request context during testing.
4. Click **Test Configuration**. The **Resolved Approvers** section shows the email addresses that would be assigned as approvers.

If the test returns no results or an unexpected value, check that the referenced lookup table is populated, the custom property values are set on the selected profile, and the attribute names match your definitions.

### Using a Dynamic Approver in a policy

Once a Dynamic Approver is configured, link it to an approval step in an Access Request Policy:

1. Go to **Lifecycle Management** > **Settings** > **Access Request Policies**.
2. Create or edit a policy.
3. Under **Approver Settings**, add or edit an approval step.
4. Set the step category to **Dynamic**.
5. Under **Dynamic Approver Settings**, select the Dynamic Approver pipeline to use.
6. Optionally, configure any users or groups that should always be assigned alongside the dynamic approver.
7. Save the policy.

When an access request matches this policy, Veza runs the selected Dynamic Approver pipeline at request time to determine the approver(s) for that step.

### See Also

* [Access Profiles — Custom Properties](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md#custom-properties)
* [Lookup Tables](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/lookup-tables.md)
* [Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.md)
* [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-hub/settings.md)


---

# 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/lifecycle-management/profiles/dynamic-approvers.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.