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.

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.

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).

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

1. Primary IdP Lookup: The default method uses the main (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

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.

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

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 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:

Overview

For organizations with many users and access reviewers, enabling a global Identity Provider (IdP) eliminates the need to manually specify additional reviewers by email, or create additional Veza user accounts for reviewers. When enabled:

• Administrators and Operators can create reviews and assign reviews for any IdP user in a domain.

• Any IdP user able to log in to Veza with single sign-on (SSO) can authenticate without the need to provision an account beforehand. See Sign-In Settings to enable SSO.

• can be auto-assigned as reviewers.

• can be used to assign reviews when you have multiple sources of employee records (e.g., contractors in one system, managers in another).

Configure a Global IdP in the Veza UI, which previews the mapping before you save it. The API remains available for earlier releases and for alternate manager lookups, which have no UI. Your Veza deployment engineer typically performs the initial configuration during onboarding. For further assistance, open a ticket with Veza Support.

A tenant has one Global IdP configuration. Saving a new configuration replaces the existing one.

Available in Veza v2026.9.21 and later. On earlier releases, use the API described in .

You need an integrated identity provider in the Access Graph and the correct auth_provider_id before you start. See . The page also requires at least one enabled SAML or SSO authentication provider. Without one, the page shows This feature requires a configured IdP and no Configure button.

1. Open Administration > Global IdP Settings.

2. Select Configure. If a configuration already exists, select the edit icon on the IdP Settings card instead.

3. Complete the fields, then select Continue:

The property fields offer the properties defined on the entity type you selected, so choose User type first.

The wizard does not set active_user_conditions or case_insensitive_match. Editing a mapping in the UI keeps their existing values. To change them, use the API.

The second step of the wizard, Preview IdP mapping, runs the proposed configuration without saving it and lists the results in three columns:

Use the search box to check a specific user by exact email address.

An empty Manager column means manager auto-assignment does not resolve for that user. The most common cause is a manager reference that does not match any value of the User Identity Property you configured. See for how manager references resolve.

The preview lists every value of a list-valued Manager Identity Property, but reviewer auto-assignment uses only the first. More than one manager in the preview can indicate a misconfigured mapping.

Use the API on releases earlier than v2026.9.21, or to configure alternate manager lookups. Otherwise, use the , which previews the mapping before you save it.

Administrators with API access can call these endpoints in the private/ namespace. APIs in the private namespace are subject to change as features are added or modified. See the following sections for prerequisites and API request format.

• The Access Graph must contain entities for an integrated provider data source. See the integration guides for:

Retrieving the auth_provider_id

Your Veza support representative can help retrieve the auth_provider_id. Alternatively, you can retrieve it directly with the following API calls:

GET /api/private/auth_providers

This will return a list of all configured authentication providers. To find the correct value:

1. Identify which authentication provider your users use to log in to Veza:

   • If using SAML: Find the entry with "auth_provider_type": "SAML_AUTH_PROVIDER" and "enabled": true

   • If using OIDC: Find the entry with "auth_provider_type": "SSO_AUTH_PROVIDER", "auth_provider_implementation": "OIDC"

Example response excerpt for a SAML provider:

In this example, the auth_provider_id would be 2017389d-a2e1-4849-a596-c1a1bd308fbc.

You can also check the current Global IdP settings:

GET /api/private/workflows/access/global_settings/idp_settings

Note: These endpoints require an administrator API key to access.

For detailed API endpoint documentation including request examples, see .

PUT /api/private/workflows/access/global_settings/idp_settings

Enable Veza to suggest reviewers from the graph by specifying the SSO auth_provider_id and identity provider data source instance_id.

idp_type is required when user_type is CustomIDPUser: set it to the idp_type defined for that custom provider. Always send active_user_conditions as an array, even for a single condition, as in [{"fn": "EQ", "property": "is_active", "value": true}]. There is no not-equal function: negate a condition with "not": true. Whenever the request includes idp, the three property names (user_identity_property, instance_id_property, and manager_identity_property) are all required and must be lowercase snake_case; an empty or omitted value returns

Notes:

• auth_provider_id identifies users with entries in the local user database and will also map correlated graph entities.

• There can be several instances of an identity provider for a given user_type.

• instance_id ensures the user info is pulled from the correct instance and domain.

Replace <AUTH_PROVIDER_ID> with the id value retrieved from /api/private/auth_providers for your SSO provider.

Okta:

Microsoft Azure AD:

Custom Identity Provider. idp_type is required when user_type is CustomIDPUser:

When your SSO provider doesn't guarantee unique email addresses across your organization, Access Reviews can use a configurable external ID from your SSO authentication to reliably match users for reviewer assignment and auto-assignment features. This integration requires coordination between your SSO attribute mapping configuration and the Global IdP settings described above.

The key relationship is between the SSO external ID configured in your SAML or OIDC attribute mapping and the user_identity_property setting in your Global IdP configuration. These values must contain matching data for users to be correctly identified during Access Reviews operations.

For example, if your Okta integration uses idp_unique_id as the user_identity_property (sourced from Okta's login field), you would configure your SSO external ID mapping to read from the login attribute in your SSO provider claims, since both properties contain the same unique identifier values for each user.

This alignment enables Access Reviews to:

• Reliably match SSO authenticated users with their corresponding graph entities during reviewer assignment

• Auto-assign managers and resource owners based on graph metadata, even when email addresses are not unique

• Maintain consistent user identification across SSO authentication and Access Reviews workflows

To configure SSO external ID for Access Reviews integration, see the SSO attribute mapping documentation for your authentication method. The external ID configuration is part of your SSO setup and works automatically with existing Global IdP settings once properly aligned.

Test your configuration by creating a review and selecting reviewers:

• If the user_type, instance_id, and instance_id_property are correct, identities from the graph will appear in the suggestions.

• If auth_provider_id is correct, SSO users should only appear once in the scenario above. The local user entry is filtered from the list. Only the user record from the graph entity will appear.

Testing SSO External ID Integration

When SSO external ID is configured, you can verify the precedence hierarchy and fallback behavior:

Precedence Verification: Create a test user with both email and external ID values in your SSO provider. When this user authenticates to Veza and appears in reviewer assignment, the system will use their external ID for Access Reviews user matching, taking priority over email-based matching.

Fallback Testing: Configure a test user with email but no external ID value in your SSO provider claims. This user should still authenticate successfully and be available for reviewer assignment, demonstrating that missing external ID values automatically fall back to email-based matching without authentication failures.

Configuration Alignment: Verify that the external ID values from your SSO provider match the data in your user_identity_property field for graph entities. Users should be consistently matched between SSO authentication and reviewer assignment, enabling reliable auto-assignment features even when email addresses are not unique in your SSO provider.

Expected behavior when configured correctly:

• Identities from the graph appear in reviewer suggestions (validates user_type, instance_id, instance_id_property)

• Each SSO user appears only once as their graph entity (validates auth_provider_id)

If you see duplicate users (both local user and graph user for the same person):

• The auth_provider_id does not match your SSO provider's ID

• Retrieve the correct value from /api/private/auth_providers and update your configuration