> 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-reviews/configuration/global-idp-settings/alternate-manager-lookup.md).

# Alternate Manager Lookup

How to configure and use alternate manager lookups for access review auto-assignment.

### Overview

Alternate manager lookups provide enhanced review auto-assignment by allowing Veza to identify managers from multiple sources of identity metadata. This is particularly useful if your organization has complex identity structures with more than one identity provider (IdP).

You may need to configure an alternate identity provider for manager assignments to enable:

* Automatic manager assignment for contractors tracked in a separate IdP (e.g., a custom OAA IdP) with managers from a primary IdP (e.g., Okta).
* Auto-assigning access reviews involving users in the main IdP (e.g., Okta Users), when manager information is maintained in another system (e.g., Oracle HCM).

By supporting cross-source manager lookups, Veza ensures consistent and accurate access review assignments, regardless of where user or manager identities are maintained.

#### Example Implementation

Alternate lookups are intended for situations where you have a primary identity provider and additional sources of identity in another system. For example, you might import identity data for contractors via a custom CSV, and want to have their access reviewed by managers who are Okta users. In this case, you want to ensure that:

* Contractor access reviews are assigned to their actual managers (who are Okta users).
* Even if the contractor identity lacks a direct manager attribute in the custom IdP, Veza can still identify the correct manager from Okta.

With an alternate manager lookup, you can configure Okta as a primary IdP, and a the imported CSV provider as the secondary IdP. When a contractor's access is reviewed, the system will first check if they have a linked user in Okta. If no linked user or manager is found, it uses the alternate lookup settings to find the appropriate manager in Okta.

### How It Works

When creating an Access Review, administrators can choose to auto-assign rows to individual managers. Veza will identify managers using one or more identity providers.

For auto-assignment to function:

* Users in the review must be linked to an identity, either in the main IdP, or one of the alternate lookups. This connection is made based on the attribute mapping in your Global IdP settings.
* The connected identities must have an attribute that contains one or more identifiers used to look up each user's manager(s). The attribute could be `managers` or any other attribute configured in your settings (`manager_identity_property`).

{% hint style="warning" %}
**Veza resolves managers in the main IdP.** An alternate lookup changes the entity that Veza reads a manager identifier from. It does not change what Veza matches that identifier against. In every case, Veza matches the value against the main IdP `user_identity_property`, on entities of the main IdP `user_type`.

A manager reference that is meaningful only in the alternate source cannot resolve, and Veza leaves the row unassigned without reporting an error. This is the most common reason that an alternate lookup has no visible effect. If your alternate source stores manager references in its own identifier space, such as worker IDs in an HRIS, map that attribute to values of the main IdP `user_identity_property`, or provision the manager in the main IdP.
{% endhint %}

Veza supports looking up managers from both primary and alternate identity providers:

1. **Primary IdP Lookup**: The default method uses the main [Global Identity Provider](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings.md) (e.g., Okta) to find managers based on configured manager properties.
2. **Alternate Manager Lookup Settings**: When the primary lookup fails, the system can use one or more alternate IdP settings to find managers.

Each alternate lookup takes five settings, and all five are required. Veza rejects an entry that is missing **User Identity Property**, **Manager Identity Property**, or **Instance Id Property**. When you save an entry that is missing **User Type** or **Instance Id**, Veza discards it without reporting an error, and the entry does not appear when you retrieve the settings. Check these settings first when an alternate lookup has no visible effect:

* **User Type**: The type of user in the alternate IdP User, e.g., `OAA.Oracle HCM.HRISEmployee`
* **User Identity Property**: The property used to identify users across systems, e.g., `customprop_manager_employee_number`
* **Manager Identity Property**: The property containing the manager reference, e.g., `customprop_manager_employee_number`
* **Instance Id Property**: The property containing the instance ID, e.g., `datasource_id`
* **Instance Id**: The ID of the alternate IdP instance, e.g., `05bbc13d-bf25-45f2-ba09-03e5625a3b66`

Order matters when configuring more than one alternate source of identity. Veza checks the primary IdP first, then the first alternate lookup, then the second, and so on, stopping at the first lookup that resolves a manager.

Notes:

* For reviews initiated using the main IdP (for example, Okta), the system looks up managers from alternate sources (for example, Oracle HCM).
* The system also tries alternate lookup methods if the primary lookup fails.
* The manager identity property can hold a single value or a list of values. When it holds a list, Veza uses only the first value, assigns one manager per row, and does not try the remaining values.
* When a user is linked to more than one identity in a source, Veza uses only the first linked identity.
* `case_insensitive_match` and `active_user_conditions` are settings on the primary IdP only. Alternate lookups take the five settings above and nothing else.

#### Manager Lookup Process Flow

```mermaid
flowchart TD
    A["User in review"] --> B{"Is the user of the main IdP type?"}

    %% Reading a manager identifier from the main IdP
    B -->|Yes| C["Read the manager identifier<br/>from the user's own entity"]
    B -->|No| F["Find the linked user in the main IdP"]
    F --> C

    %% The match is always against the main IdP
    C --> R{"Does the identifier match a main IdP<br/>user's user_identity_property?"}
    R -->|Yes| Z["Manager assigned"]
    R -->|No| I{"Any alternate lookups left?"}

    %% Alternate lookups supply a candidate identifier, nothing more
    I -->|No| J["No manager assigned;<br/>the row is left unassigned"]
    I -->|Yes| E["Next alternate lookup,<br/>in configured order"]
    E --> G["Find the linked user<br/>in the alternate source"]
    G --> H["Read the manager identifier<br/>from that entity"]
    H --> R
```

Both match steps test against the main IdP. Alternate lookups change only the entity that supplies the candidate identifier.

### API Configuration

Alternate manager lookups have no user interface. Unlike the primary Global IdP, which you can configure under **Administration** > **Global IdP Settings**, you can set alternate lookups only through a `private/` API request. Your Veza support representative can help configure this global setting.

You can also use an administrator [API Key](/4yItIzMvkpAvMVFAamTf/developers/api/authentication.md) to call the endpoints below:

* **PUT** `/api/private/workflows/access/global_settings/idp_settings`
* **GET** `/api/private/workflows/access/global_settings/idp_settings`

The global IdP settings request takes an `idp` settings object for the primary IdP configuration, and one or more secondary IdPs defined in `alternate_manager_lookup_settings`. A request that includes `idp` replaces the primary configuration, so send the full settings object each time, including any alternate lookups you want to keep.

Each entry in `alternate_manager_lookup_settings` must set all five fields. The three property names, as on `idp`, must be lowercase snake\_case; an empty or omitted value returns `400`. Veza discards an entry without `user_type` or `instance_id` without reporting an error, and a `GET` does not return it.

For example:

```json
{
    "value": {
        "enabled": true,
        "idp": {
            "auth_provider_id": "87549440-ef3d-4f8c-a3d8-ed1569a79ed6",
            "user_type": "OktaUser",
            "instance_id": "instance.okta.com",
            "user_identity_property": "employee_id",
            "instance_id_property": "datasource_id",
            "manager_identity_property": "x_manager_id"
        },
        "alternate_manager_lookup_settings": [
            {
                "user_type": "OAA.Oracle HCM.HRISEmployee",
                "instance_id": "05bbc13d-bf25-45f2-ba09-03e5625a3b66",
                "user_identity_property": "employee_number",
                "instance_id_property": "datasource_id",
                "manager_identity_property": "managers"
            },
            {
                "user_type": "OAA.Contractors.IDPUser",
                "instance_id": "9fb32fc1-4db2-4ac6-9ab1-b5c24836ddd4",
                "user_identity_property": "idp_unique_id",
                "instance_id_property": "datasource_id",
                "manager_identity_property": "customprop_manager_employee_number"
            }
        ]
    }
}
```

{% openapi src="/files/Aco9gj4MY2XoNiD4zIjr" path="/api/private/workflows/access/global\_settings/idp\_settings" method="put" %}
[openapi.yaml](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-c990b1c25368cfe24114b6d88a4d362095219709%2Fopenapi.yaml?alt=media)
{% endopenapi %}

{% openapi src="/files/Aco9gj4MY2XoNiD4zIjr" path="/api/private/workflows/access/global\_settings/idp\_settings" method="get" %}
[openapi.yaml](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-c990b1c25368cfe24114b6d88a4d362095219709%2Fopenapi.yaml?alt=media)
{% endopenapi %}


---

# 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-reviews/configuration/global-idp-settings/alternate-manager-lookup.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.