Overview

Reviews you create can be organization-wide, or constrained to specific applications or populations of users. Use the query builder to scope reviews to meet the needs of your organization based on what data sources you have integrated, the specific compliance requirements of your organization, and existing review processes. For instance, a review configuration might specify:

• All users with specific permissions on all databases of a certain type.

• Users with any access to an individual application.

• Access for a subset of users, based on an attribute, such as "department."

The results of the query are used to compile the list of items included in an individual access or entitlements review. Depending on the objective of the review, these items can be further enriched with:

• System and Effective Permissions for a relationship, such as the permissions that a user has when accessing a particular resource

• A summary of the path that made the access connection - useful to show that an intermediary group or role is granting a user access

• Additional metadata about the source or destination entities to provide more context to reviewers.

Queries are especially powerful when entities in your access graph have attributes or tags defining ownership, applicability to compliance rules or regulations, regional metadata, and other organizational attributes. Additional metadata can include Veza tags, native tags originating from the data source (i.e. AWS tags), and Open Authorization API custom properties, as well as details about a related identity from your Identity provider or HRIS system.

This document provides an overview of all configuration options and guidance on using entity type groupings to review access for many entity types using a single configuration.

This document provides an overview of all configuration options and guidance on using entity type groupings to review access for many entity types using a single configuration.

When defining the scope of a review configuration, you can choose between two approaches:

• Quick Builder: A simplified option for common use cases. Choose an application, select a review type (e.g., "Okta user AWS IAM group memberships"), and optionally narrow the scope with data source filters. Best for standard access review scenarios without complex filters.

• Advanced Query Builder: Full control over source/destination entity types, filters, permissions, intermediate entities, and relationship options. Use this for custom or complex review scopes. The remainder of this document describes the Advanced Query Builder options.

For 1-step access reviews (Early Access), see .

The following table describes the options when defining an access review's scope with the configuration query builder.

Note that these options can differ from those available in the Access Visibility query builder, and include parameters specifically designed for access reviews. The entity types available as query source or destination depend on your configured integrations.

Use entity type groupings in a configuration to include several entity types in the scope of an access review. Choosing an entity type grouping as the source or destination will include all entities within that grouping. Use these to construct queries such as "All Principals to all Custom Application Role," or "All Top Level Principals to GitHub Repositories."

• All Principals: Entities with the Identity label, including machine entity types that can have permissions on resources.

• All Top Level Principals: Identity-type entities that cannot be assumed by another identity. Use this option to show primary organizational identities (e.g., IdP users), and filter out any low-level identities (such as local users) they can assume. Reviews will contain local users and service accounts that don’t have an upper-level identity.

Some special entity type groupings are provided specifically for Access Reviews. These return all "custom" users, roles, resources, and other entities added to Veza using Open Authorization API templates. These groupings enable scoping reviews to for all users or resources in custom applications, identity providers, and HRIS platforms:

• Custom Applications

• Custom Subresources

• Custom Resources

• Custom Users

Custom entities and their attributes are defined in the JSON push payload created by OAA connectors. For more information about these entity types and attributes, see .

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

Typically, your Veza deployment engineer will perform initial IdP settings configuration during onboarding. If further assistance is needed, Veza Support can help through a support ticket.

Administrators with API access can also make these calls directly using endpoints in the private/ namespace. 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:

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"

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:

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:

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.

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

Overview

When creating a review or choosing to Reassign Reviewers, administrators can assign one or more default reviewers for all rows and auto-assign reviewers for individual rows. When auto-assigning reviewers, fallback reviewers are used for any rows where an owner or manager cannot be identified, or would be prevented from review for any reason.

This document describes how possible candidates are evaluated, and the behavior when a reviewer can’t be found or automatically assigned. The Veza support team can help you customize reviewer selection methods for your tenant.

Learn more:

• Managers and Resource Owners: Enable auto-assignment of a manager or resource owner.

• : Block users from reviewing their own access.

• : Maintain a list of users prevented from reviewer assignment.

• : Appoint users as subordinate reviewers in the place of specific users.

• : Configure fallback reviewer selection methods via API (Early Access).

Rows in an access review can be assigned to the possible candidates:

• Reviewers: Default reviewers assigned to all rows, specified at review creation. There can be more than one default reviewer for a review.

• User Managers / Resource Owner: A user identified as the manager of the employee whose access is under review, or a resource owner.

• Fallback Reviewers: Assigned when a user manager or resource owner cannot be found, or if a rule would prevent assignment (such as self-review prevention or the reviewer deny list). There can be more than one fallback reviewer.

Veza uses the following logic when assigning reviewers for a new review, and when rows are re-assigned after review creation:

• Reviewers are all candidates for assignment. User and Resource Managers are also candidates.

• Fallback Reviewers become candidates when no candidates are available or allowed for assignment.

• If a rule prevents a candidate's assignment, the other specified Reviewers are assigned.

When a valid candidate can't be found, Veza can assign that reviewer's manager, fallback reviewers, the workflow creator, or a Veza local user with the administrator role.

Administrators can change this global setting using the , or the Veza Customer Success team can configure it on your behalf. If the first selection method can find at least one allowed alternate reviewer, the user is assigned. Otherwise, the next selection method is attempted. Possible selection methods are:

• REVIEWERS_MANAGER | Assign the manager of the prevented candidate.

• CERTIFICATION_ALTERNATE_REVIEWERS | Assign to the first valid Fallback Reviewer, for certifications created using auto-assignment.

• WORKFLOW_CREATOR | Assign to the workflow creator.

For example, with the selection methods:

Veza will not assign the workflow creator or a system administrator as a fallback behavior. Instead, Veza will:

1. Assign the denied candidate's User Manager (if allowed).

2. Otherwise, assign the first valid Fallback reviewer.

3. Assign no reviewers for results where a valid manager or fallback reviewer does not exist.

Overview

Review Intelligence Policies can reduce the time reviewers spend working on reviews by automatically making decisions on rows based on filter criteria or previous decision status. They define rules to compare the current review rows with the most recently completed or expired review for the same configuration, and act on rows that are the same in the new and previous certification.

For example, a policy can "Reject rows where identities have no recent activity" or "Approve previously approved and unchanged" access.

Two default rules are optionally available for all reviews, and can be added when creating a review:

• “Approve previously approved and unchanged”

• “Rejected previously rejected and unchanged”

Additionally, administrators can create custom policies and attach them to configurations with the .

An automation definition includes:

• The criteria, such as “Row is unchanged from the previous review and was previously approved”

• The action, such as “Approve & Sign-off”

• Whether it is available for all or some configurations

• Whether it runs by default

Automations with the HIGHLIGHT display style can use a custom highlight_color to visually distinguish matching rows in the reviewer interface. The color is specified as a hex code (e.g., #FF0000 for red, #FFA500 for orange). See the for details.

Operators can apply available Review Intelligence Policies when creating a review. These rules can also run by default at the start of any review.

1. Create a configuration or search for an existing one on the Access Reviews page.

2. Start or schedule a review for the configuration and enable automation by clicking Use Review Intelligence Policies.

3. Enable the rules to run from the dropdown and save your changes.

Open the result actions dropdown and click View Action Log to see when a rule was executed for a single result.

Administrators and operators can review all automated decisions by opening a review and checking the status bar above the table. A chart indicates the total action count.

The options when creating reviews will depend on the Review Intelligence Policies available to the review configuration.

Administrators can use and other API operations to manage these rules, and set whether they run by default or on an opt-in basis. An attachment operation assigns a single rule, or all rules, to a configuration.

Columns in the review interface can be customized to rearrange, show, or hide certain attributes. Configuring default columns can improve overall readability, and offer reviewers valuable context for each row. Note that changes to columns made in the Veza UI will be saved to the browser. If a user has already customized a certification's columns, changes to the default settings will not apply.

You can also change the default order in which rows appear. For example, you might want to show results in descending order by destination resource type. This can be useful to encourage reviewers to focus on particular rows earlier in the review.

A set of global default columns and sort method applies to all reviews. You can also configure custom column orders for all reviews created for a specific configuration.

There are two ways to set default columns:

Early Access: Please contact the Veza support team to enable this feature.

1-step access reviews enable administrators to quickly create, delegate, and initiate access reviews, without first creating a reusable review configuration.

The 1-step review wizard provides a streamlined builder for defining the scope of the review based on:

• Pre-defined scopes for common scenarios and applications such as Okta, AWS, and Salesforce.

The Action Allow List restricts two sensitive review operations to users granted roles that explicitly permit these operations:

• Deleting an In Progress review

• Modifying the due date of an In Progress review

When the action allow list is enabled, only users on the list can perform these operations, regardless of their assigned Veza role. When it is disabled, the standard role-based access controls apply unchanged.

How It Works

When the allow list is enabled:

• Users on the list retain the ability to delete In Progress reviews and modify their due dates.

• Users not on the list will not see the Delete or Edit Due Date options in the review management interface.

• API requests to delete or modify the due date of In Progress reviews are also rejected with a permission error for users not on the allow list.

Disabling the allow list restores default behavior immediately. No entries are removed — the list persists if you re-enable later.

When the action allow list is disabled, the standard apply. By default, users with the admin, operator, or access_reviews_admin role can delete In Progress reviews and modify their due dates.

To check the current state:

Returns {"enabled": true} or {"enabled": false}.

To enable:

To disable:

Both individual users and Veza groups can be added to the allow list. A user is permitted if their user ID is directly on the list, or if any group they belong to is on the list.

All IDs must be Veza internal UUIDs — not email addresses or usernames.

To find a user's UUID:

• Administration console: Go to Administration > Users, click the user's name, and copy the UUID from their profile page.

• Users API: Use the to retrieve users and locate the id field in the response.

To find a group's UUID:

• Administration console: Go to Administration > Group Management. The group UUID is not shown in the table view — use the API to retrieve it.

• Groups API: Use GET /api/private/groups to list groups and locate the id field for the target group.

Use the filter query parameter to narrow results by name: ?filter=name eq 'Your Group Name'.

Add a user:

Add a group:

Remove a user or group:

List all permitted principals:

For the complete API reference including request and response schemas, see .

Predefined Questions enable organizations to require reviewers to answer specific questions when making review decisions. Enabling this feature can help meet compliance requirements and provide a structured context for each reviewer's decision.

For example, when approving access, reviewers might be asked, "What is the business justification for this access?" with predefined options like "Required for current project," "Ongoing operational need," or "Temporary access for incident." For rejections, questions might include "Why is this access no longer needed?" or "Should this access be immediately revoked?"

Administrators can customize question sets in Access Reviews > Settings > Question Sets.

Overview

Questions are configured in Question Sets. Each review configuration can optionally be associated with different Question Sets - one for Approve and another for Reject responses. When configured, reviewers must answer all questions in the specified Question Set before submitting their decision (approve or reject). During bulk decisioning, one set of answers applies to all selected rows.

After creating a review that uses predefined Question Sets, a permanent record of those questions is stored with that review. In other words, if you edit a question set associated with a specific configuration, it will only affect future reviews.

Question responses are automatically included in webhook payloads for downstream processing and compliance reporting.

Question Sets are reusable collections of questions that can be attached to review configurations. Each question set contains:

• Name: A unique descriptive name for the Question Set

• Description: Optional details about the Question Set's purpose (this field is not currently configurable in the UI, and is an optional property in the API)

• Questions: An ordered list of questions to be answered

Questions can be configured in two ways based on how you want reviewers to respond:

1. Multiple Choice: Present predefined answer options. Answers appear in the configured order, and can include an "Other" option for free-form text response

2. Free Form: Allow reviewers to enter any text response

Within the review configuration, you can configure different Question Sets for:

• Accept decisions: Questions asked when approving access

• Reject decisions: Questions asked when denying access

Question Sets are managed separately from review configurations, making them reusable across reviews.

1. Navigate to Access Reviews > Settings > Question Sets (requires Admin or Access Review Admin role)

2. Click Create Question Set

3. Provide a descriptive name (e.g., "Security Access Questions") and optional description

Note: Question Sets that are in use (applied to a review) can be modified, but any active running reviews will continue to use the earlier version of the Question Set from when the review was created. Deleting a Question Set will not impact existing reviews created using those questions.

You can assign predefined Question Sets when creating or editing a review configuration:

1. In the configuration builder, navigate to the Predefined Questions step

2. For On Accept, select a Question Set from the dropdown (optional)

3. For On Reject, select a Question Set from the dropdown (optional)

Based on the review configuration, users assigned to an access review are prompted to respond to the assigned questions when approving or rejecting individual rows, including when making decisions in bulk:

When a reviewer decides on a row:

1. Upon clicking Approve or Reject, a dialog appears with the configured questions

2. Questions are displayed in their configured order

3. The reviewer must answer all questions

When decisioning multiple rows at once:

1. One set of questions appears for all selected rows

2. The same answers are applied to all rows in the bulk update

Some special behaviors apply during multi-level approval workflows. First-level reviewers are required to provide answers, while subsequent reviewers can make edits to previous answers:

1. First Level: Reviewers answer questions when making decisions

2. Propagation: When decisions move to the next level, question responses are automatically copied

3. Editing: Next-level reviewers can modify the responses before signing off

• Questions cannot be conditionally required based on other answers (in initial release)

• Question Sets cannot be modified while actively used in running reviews

Overview

Digest Notifications consolidate notifications for Access Reviews into digestible summaries, helping engage reviewers without excessive individual alerts. When enabled, reviewers will receive periodic emails with a list of pending tasks across multiple access reviews. Digest notifications can be configured on the Access Reviews > Settings > Notifications tab.

To limit the total number of emails to reviewers while keeping them engaged and informed of their assignments, Veza recommends enabling Digest Notifications as a global setting, on a daily, hourly, or weekly basis. Administrators can supplement these with additional notifications as needed by configuring notifications and reminders for specific reviews.

Digest Notifications complement any notifications and reminder emails configured in Review Notification Settings. When enabling the feature, you should check your review-level email settings and disable them to avoid redundant notifications.

Administrators can enable Digest Notifications on the Access Reviews > Settings page, and customize the delivery interval and snooze periods. Digest Notifications are disabled by default.

Digest Email: Reviewers receive a summary of all reviews where they have remaining work to do (i.e., assigned rows that are not yet signed off). This includes:

• The list of reviews with incomplete review tasks.

• The number of remaining rows assigned to the reviewer.

• A reminder if any of the reviews are new or overdue.

Normal Delivery: The regular frequency for digest emails (weekly by default). Administrators can adjust the delivery interval based on your review cadence and reviewer feedback.

Snooze: Use the Snooze feature to prevent notifications on certain days, such as weekends. Administrators can customize the days of the week when emails are not sent.

Exclusion Settings: Configure label-based exclusions to prevent specific certifications from being included in digest notifications. Reviews with any of the selected labels will be excluded from digest emails, giving administrators granular control over which reviews generate notifications.

Global Digests: Review Notification Settings coexist with individual review notification settings. This setting affects all assigned reviewers, excluding denied recipients managed under Access Reviews > Settings > Reviewer Deny List.

To configure Digest Notifications:

1. Navigate to Access Reviews > Settings.

2. Locate the Digest Notifications section.

1. Toggle the Enable switch to turn Digest Notifications on or off.

1. Under Normal delivery, select how often users should receive digests for regular notifications:

2. Choose the frequency:

   • Set the number (1-6 for days, 1-23 for hours)

For example, "Deliver every 1 day" will send daily digests. When enabled, daily digests are sent at 11:AM PST, and weekly digests at 11:AM PST each Monday.

1. Under Snooze, select the days of the week when notifications should not be delivered.

2. Check the boxes next to the days you want to exclude from notification delivery.

To exclude specific reviews from digest notifications based on labels:

1. Expand the Exclude reviews section within Digest Notifications.

2. Select one or more labels from the dropdown.

3. Changes save automatically.

Reviews with any of the selected labels will be excluded from digest notifications. For alert notification exclusions, see .

Administrators can control which users receive digest emails through the Digest Notification Recipients system setting. This setting is available under Administration > System Settings.

To customize the content, styling, and branding of digest notification emails, see in the Administration section.

• - Notification system concepts and delivery channels

• - Customize notification content

• - Complete delivery settings reference

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

Early Access: On-Demand Reviews are currently provided as an Early Access feature. Please contact the Customer Success team to enable this functionality on your Veza platform.

Overview

Veza Access Reviews support on-demand reviews using Access Intelligence alert rules and Lifecycle Management triggers. By attaching review creation rules to saved queries, you can trigger the creation of new reviews in response to changes in your authorization environment. This type of access review might be initiated whenever new user accounts are detected within an application, new entitlements are granted, a user's risk level increases, or if MFA is removed or disabled for an account.

On-demand reviews support Review Intelligence rules, and are created with a duration and reviewer assignments based on the rule configuration. These reviews automatically focus only on changed items, filtering out entities that haven't been modified since the last review.

Common scenarios for implementing on-demand reviews include:

• Automatically reviewing access for terminated employees

• Certifying access when users are added to new roles

• Validating permissions after attribute changes

• Reviewing orphaned or inactive accounts

Important concepts:

• Rules are conditions attached to saved queries that trigger automated actions when met.

• Create Reviews settings define how new reviews will be created when rule conditions are met.

• Rule Triggers are attribute-based or change-based criteria that initiate review creation (for example, when the query results have increased, or when an entity's is_active attribute changes).

Before configuring on-demand reviews, you will need to:

1. Create at least one access review configuration defining the scope of reviews.

2. Build and save a query that identifies the entities requiring review, or use a built-in query.

To add a review creation rule:

1. Navigate to the saved query

2. Select "Manage Rules" from the actions menu

3. Click "Add New Rule"

4. Configure the rule details:

See for more on working with existing queries.

To configure the Create Reviews settings:

1. Click Configure New On-Demand Review

2. Select an existing review configuration that is compatible with the entity types returned by your rule query.

   For example:

   • If your query returns Okta users, select a configuration designed for user reviews

New reviews will start based on this creation plan when the rule conditions are met. Note that on-demand reviews are always created from the most recent graph snapshot data when the rule activates.

See for details on configuring new reviews.

On-demand reviews are created in one of two modes depending on review requirements and the scope of results.

Consolidated Mode (CONSOLIDATED) creates a single access review containing all entities that triggered the rule. The review uses the full scope of the original query. This typically works best for large datasets, broad policy enforcement, and simplified review management.

Individual Mode (INDIVIDUAL) creates separate access reviews for each entity that triggered the rule. Each review is filtered to show only the specific entity that triggered the rule. This mode enables entity-specific reviews, allowing more granular oversight with unique reviews for each result that can be distributed across reviewers.

Automatic Fallback Behavior

Veza implements automatic fallback mechanisms for automated review creation:

• Performance Thresholds: When more than 1,000 results are triggered, Veza falls back to creating a review using the standard query configuration without entity-specific information. This fallback applies to both Consolidated and Individual modes to ensure optimal performance.

• Individual Mode Limitations: Individual mode is currently limited to 20 triggered entities. When this limit is exceeded, the system automatically creates a single consolidated review containing all triggered entities instead of separate individual reviews.

• Configuration Validation Fallback: When triggered entities don't match the configuration's expected identity types, the system automatically creates a broader review using the original query scope without entity-specific filtering. This ensures reviews are still created even when there are configuration mismatches.

On-demand reviews include built-in error handling to ensure reliable operation:

Configuration Compatibility Issues: When triggered entities don't match the configuration's expected identity types, the system automatically falls back to creating a broader review using the original query scope without entity-specific filtering. This means the review will include the full result set of your original query, not just the specific entities that triggered the rule.

Mixed Entity Types: If the Query associated with the Rule returns different types of entities (users, roles, resources), ensure your configuration can handle all entity types, or expect the system to fall back to a broader review scope.

Review Creation Failures: Before creating reviews, the system validates that the review configuration is compatible with the triggered entities. If individual review creation encounters errors, the system logs the failure and continues processing remaining entities to ensure partial success rather than complete failure.

• Rules are evaluated on a regular schedule aligned with data extraction intervals (typically during each data refresh cycle)

• Multiple rules can be attached to a single query

• Each rule can include more than one review creation plan

Auto-revocation automatically removes a user's access when a reviewer rejects and signs off a row during an access review, without the need for webhooks or custom integrations to facilitate access removal.

On sign-off of a rejected row, auto-revocation triggers and removes the user from the target entitlement — such as a group, role, permission set, or license.

This feature is available with Access Reviews Advanced and is limited to applications and entity types with provisioning and deprovisioning support enabled.

Consider a User to Group access review targeting the Marketing Team group in Okta:

Controlled Access: This feature is currently only enabled for customer tenants on a controlled basis.

Veza Access Reviews optionally supports a two-tier review and approval process, where two different parties sequentially review and approve a Review.

When second-level reviewers are enabled for a new review, two levels of review and sign-off are needed before rows in the review are marked "completed.". Each review level is assigned to different reviewers. Both levels of a review support reviewer auto-assignment, though options vary depending on the review level.

Note that each review level can have multiple reviewers assigned per row — just like a typical single-level review.

Key concepts for multi-level reviews include:

Overview

Notifications inform reviewers and other stakeholders of important events, such as when a review starts, re-assignments occur, and deadlines pass. These notifications can be delivered via email, Slack, or both. Veza includes three types of notifications, which an administrator can customize with templates.

• Notifications: Event-based, sent when a review starts or finishes, or on row reassignment.

• Reminders: Time-based, sent around the deadline or period of activity when there is remaining work.

• Final Reminders: Similar to reminders, highlighting missed deadlines or extended periods of inactivity.

Access Review notifications can be delivered through multiple channels:

• Email: Traditional email notifications sent to reviewers, managers, and additional recipients (default)

• Slack App: Direct message notifications sent to individual reviewers via the Veza Slackbot

You can enable one or both delivery methods based on your team's preferences. When both are enabled, reviewers receive notifications through both channels simultaneously.

To enable Slack App notifications:

1. Configure the Slack App integration (see )

2. The feature flag UI_SLACK_APP_INTEGRATION must be enabled for your organization (contact Veza support)

3. Users must exist in both Veza and Slack with matching email addresses

When creating or editing an Access Review configuration:

1. Navigate to the Notification Settings section

2. Under Delivery options, select:

   • Email: Send notifications via email

All configured notification events will be delivered as direct messages to assigned reviewers through the selected delivery methods.

When reviewers receive their first Slack notification:

1. If they haven't connected their Slack account to Veza, the message includes a "Connect" button

2. Clicking "Connect" redirects them to Veza's login page

3. After authentication, their Slack and Veza accounts are linked

4. Subsequent notifications include interactive "View", "Approve", and "Deny" buttons

Operators assign default notification settings when creating a configuration. Reviews created for the configuration will inherit these settings. Operators can later customize notification settings for specific reviews.

For multi-user access reviews, you will typically want to fine-tune reminders to meet your requirements, for example:

• Reviewers and review owners, informing them when rows are re-assigned.

• Reviewers and their managers, if users are inactive when further action is required.

• External stakeholders, on review completion or after a deadline passes.

This document describes notification options for Veza Access Reviews, and how to edit notifications for a configuration or a review.

You can add reminders when creating a configuration by enabling them in the Notifications section of the configuration builder. To enable notifications, specify the recipients and the conditions that will result in an email.

Recipients can be:

• Reviewers: Users assigned to rows in the review, including default reviewers and any reassigned reviewers.

• Reviewer Managers: Users identified by Veza as the manager of an assigned reviewer, possible after enabling a global identity provider for Veza Access Reviews.

• Additional Recipients: Any other stakeholders, provided as a comma-separated list of emails. You can use this option to inform external users about completion status, deadlines, and delays.

Notifications can trigger:

• On review start: Upon review creation or after publishing a draft review. Use this option to inform reviewers who are auto-assigned on review creation.

• On row reassignment: After a reviewer is assigned to a row by a user operation (API or GUI-initiated). It does not include reviewers assigned at review creation.

• On review completion: When the review is marked "Complete".

Reminders can trigger:

• Every (number of days) if no changes by reviewers in (number of days): Periodic reminders when reviewers have not acted on their assigned rows.

• On (number of days) before review due date: Sent based on an upcoming due date.

• On due date: Sent when the review is due.

Final Reminders have the same triggers and use the same template as “Action Needed” reminders. Use them to add escalated reminders, emphasizing missed deadlines or extended periods of inactivity. For example, a reminder might notify the reviewer after a few days of no activity, and a final reminder might notify both the reviewer and their manager if there have been no changes in a week.

Veza can automatically detect when an assigned reviewer's account has been deactivated or removed and notify the appropriate parties so that rows can be reassigned before the review expires.

When enabled, Veza runs a background check approximately every 24 hours while the review is in progress. It compares the current list of assigned reviewers against the integrated IdP and flags any reviewer whose account:

• Has is_active = false in the IdP, or

• No longer exists in the IdP (deleted or deprovisioned)

When inactive reviewers are detected, notification emails are sent to the configured recipients.

To enable Reassignment Needed notifications:

1. Go to Access Reviews > Configurations and open a configuration.

2. Click Edit and scroll to the Advanced Notifications section.

3. Under Reassignment Needed, check Reviewer account has been detected as inactive.

Saving changes to email notifications at the configuration level causes both active reviews and new reviews for that configuration to use the updated settings.

To change the default email notifications for an existing configuration:

1. Go to Access Reviews > Configurations.

2. Click the configuration name to view details.

3. On the Configuration Details page, click Edit.

Operators and administrators can customize notifications for individual reviews. These settings appear in the reviewer's interface on the review details sidebar.

To edit email notifications for an in-progress review:

1. Go to Access Reviews > Reviews, or open the review from the Configuration Details page.

2. Click on the review's name to open the reviewer's interface.

3. On the Review Details sidebar, find Notifications and Reminders and click Open.

To customize the email content, subject lines, and branding for Access Review notifications, see in the Administration section.

• - Notification system concepts and delivery channels

• - Customize notification content and branding

• - Configure digest schedules and recipient controls

Early Access: Enrichment is currently provided on an opt-in basis. Please contact Veza Support to enable this feature. Enrichment requires an IDP or HRIS integration such as Okta, Active Directory, Azure AD, Workday, or a Custom Identity Provider.

Overview

You can configure access reviews to show additional human resource or identity metadata for users under review. When enabled, Veza will check for matching entities in an integrated Identity Provider or HRIS platform when creating the review. The linked user attributes are shown in columns, which reviewers can show, hide, or filter by for faster and more accurate decision-making.

For example, when reviewing local Snowflake user access to Snowflake databases, enabling this option will show the attributes of the linked Okta user for each local user, such as their risk score, first and last name, and whether MFA is enabled. Local users with no linked Okta users could be machine identities, or represent risky misconfigurations.

Similarly, an access review of Okta users to Okta applications can use this option to show information about the Workday Worker associated with each user, such as the cost center, hire date, or active status.

Enabling IDP/HRIS Metadata Enrichment

To enable IDP User columns in the reviewer interface, enable enrichment in the configuration scope:

1. Create or edit a configuration.

2. In the review scope, enable Advanced Options > Enrich with IdP/HRIS data.

3. Select from the list of supported entity types to enable result enrichment (such as "Workday Worker" for "Okta User"):

In the configuration builder, choosing an entity type under the Enrich with IdP/HRIS data option enables filters on that entity type. For example, you might choose 'Okta User' as the source entity type under review and enable 'Workday Worker' as the enrichment entity type. You can then apply filters on both Okta User and Workday Worker attributes.

It is important to understand how these filters affect the review results. If an enrichment attribute does not meet the filter criteria, the enrichment data for that row is hidden, but the original access relationship remains visible. This behavior ensures that you can still see all source and destination entities, and identify rows where the enrichment data does not match the filter.

• Filters on enrichment data do not remove source or destination entities from the review. You will still see all access relationships.

• If the enrichment data does not meet the filter criteria, only the enrichment columns are affected.

• This behavior helps identify users who may not have corresponding enrichment data, potentially presenting misconfigurations.

Example:

Suppose you have a review of Local Users to Local Groups, enriched with Okta User data:

Now, you apply a filter on the Okta User column to exclude users whose names start with "A" (e.g., Okta User does not start with "A"). The updated review results will be:

In this filtered view:

• Bob's enrichment data continues to appear because it meets the filter criteria.

• Alice's enrichment data is blank because it does not meet the filter criteria (Alice starts with "A").

• The access relationship between Alice and Group2 remains visible.

Enrichment attributes appear only when Veza finds a direct identity link between the reviewed entity and the configured IdP or HRIS entity. If enrichment columns are blank for some users, the most common causes are:

• No matching identity in the integrated system. The user exists in the source system under review (for example, a Snowflake local user) but has no corresponding record in the configured HRIS or IdP.

• Integration not in scope. The IdP or HRIS integration must be within the active team scope for the review. If the integration is outside the team's scope, no enrichment data will be available.

• No identity link in the graph. Veza enriches based on direct relationships between entities in the access graph. If the integration hasn't run recently or the link between the reviewed entity and its HRIS/IdP counterpart hasn't been established, enrichment will be empty.

To investigate blank enrichment rows:

1. Confirm the HRIS or IdP integration has completed a successful extraction.

2. In Access Graph or Query Builder, verify that a path exists between the reviewed entity and the expected HRIS/IdP entity (for example, Okta User → Local User).

3. If no path exists, check whether the identity correlation attributes (such as email address or employee ID) match between the two systems.

Users with no enrichment data are often worth reviewing manually — they may be service accounts, machine identities, or accounts that exist outside your standard identity lifecycle.

When you enable IdP/HRIS enrichment for an Access Review configuration, the enriched entity data is available for use in . This enables automation scenarios such as automatically rejecting access for users without a matching identity provider profile.

Each enriched entity type in your review configuration is assigned an alias that you use to reference its attributes in automation filters. The alias is a short identifier defined when the Access Review configuration is created. Common conventions include simple names like idp or hris, or snake_case versions of the node type like okta_user.

The alias for enriched entities is set when the Access Review configuration is created and varies by configuration. To find the correct alias for your specific Access Review:

1. Check API responses (recommended): Call the endpoint for your workflow. The response includes the query_spec with join_connected_specs that shows the as field value for each enrichment.

2. Inspect browser network responses: When viewing a review in the Veza UI, open browser developer tools (F12) and examine the network responses. Look for:

Once you know the alias, you can create automation filters that reference enriched entity attributes. These examples use idp as the alias. Replace this with the actual alias from the review configuration.

Check if an enriched user exists:

Check if an enriched user does NOT exist (orphaned account detection):

Filter by an enriched attribute:

Combine source and enrichment filters:

Combine custom properties with OR logic and enrichment filters:

This automation automatically rejects local accounts that have no matching identity provider profile, helping identify potential security risks. Replace idp with your actual enrichment alias.

Overview

Veza enables access reviews across systems that involve assumed roles, inherited group assignments, and other complex hierarchies. The Relationship and Summary Entities query settings offer visibility into the exact path of access between a source and destination entity. These options can be especially useful to show relationships such as nested groups in Active Directory, SharePoint Sites and Libraries, or nested roles in Snowflake.

These configuration options enable reviewers to approve or reject not only the level of existing access, but whether the assignment is correct:

1. Show relationship: Choose one intermediate entity type (such as Okta Groups that connect Okta Users to Okta Apps). The review interface will include columns showing the name and attributes of intermediate entities, when they exist.

2. Show summary entities: Choose one or more intermediate entity types. The review interface will include a single column listing any entities of that type in the path between source and destination, and their sequence.

Depending on the used in the configuration scope, reviewers will certify the combined effective Permissions for each result, or the Summary of access and System Permissions for each result.

• System Permissions: Specific to each application, resource or platform, System Permissions are the security metadata that define what actions can be performed against a given resource. When filtering by system permissions or using system query mode, reviewers can sign off on native permissions in the provider's unique terms. System permissions ranges from simple (file shares) to extensive and extremely complex (AWS), and can be unknowable and unactionable for non-technical users.

• Effective permissions: These represent the canonical CRUD equivalents of system permissions. These are an easy-to-understand, normalized “translation” of system privileges, making technical, complicated, and application-specific concepts consistent across all applications, resources, and platforms. Access Reviews based on Effective Permissions can simplify entitlement reviews for non-technical reviewers.

In the reviewer interface, the Permissions column will be empty for configurations that use system-mode queries. In this case, an optional column lists System Permissions.

If a configuration includes a Relationship to show, rows in the reviewer interface represent connections from one entity to another, by way of the related intermediate entity. For example, AWS IAM User to AWS S3 Bucket with AWS IAM Role for the Relationship will return rows with unique connections of User connected by Role (or directly) to an S3 Bucket. A query can specify only one Relationship.

These reviews will include optional columns showing the properties of the related entity, populated whenever an entity of the chosen category exists in a results authorization path. For example, when choosing a Role for the Relationship to show, reviews will include filterable and sortable Intermediate Role columns.

This option can be preferable when access paths are relatively simple and reviewers can benefit from details about the intermediate node.

If a path involves several related entities, access reviews can include details including the exact entity types and their sequence. Note that this option will change the total number of results, and show a row for each unique source and destination path.

Selecting Summary Entities is similar to selecting an intermediate Relationship, except that several entity types are selectable at once. When included in a query, the review rows will be entities of the source category with a relationship of the destination category, and will include a summary of the path that made the connection.

The entity types selected as Summary Entities for the query appear in the summary column. For example, a query from User to Bucket with a summary including Group and Role will return all the unique results of Users connected to Buckets, along with a summarized path. The summarized path might be GroupA -> Role1, or just Role2 (if no groups are in the path). If the user has direct access to a bucket (not by way of group or role), the summary will be empty.

Access reviews that use System mode in combination with Summary Entities will not include effective permissions calculations (the "Permissions" reviewer interface column will be empty). Instead, users will be able to review the "System Permissions" and "Summary Entities" columns for their assigned results.

By inspecting the relationships between intermediate entities and the resulting system permissions, reviewers can certify how access is actually configured for identities within an organization:

For example, for a well-managed Google organization, the authorization path will typically include roles bound to groups that a principal is a member of. However, the access summary indicates possible issues — such as when a policy is directly attached to the resource it grants permissions on, and when permissions are not granted by group assignment.

Generating the summary can add additional time to review creation, and summaries can contain a limited number of total entities:

• Path Summaries that contain too many nodes will have a placeholder (...) indicating the missing intermediate entities.

• Summary details for these results will indicate that additional nodes exist, but are not shown.

Path summaries are a review visualization option that can be especially useful for understanding role-based access controls for providers such as Microsoft Azure and Google Cloud. Choosing Summary Entities when creating a configuration enables reviewers to judge whether the configured permissions are appropriate based on security policies, including:

• If permissions are granted by group or role membership, or direct assignment

• The name of the role or group granting permissions

• The objects policies apply to, such as the query destination resource (for directly applied policies) or an upper-level resource in the resource hierarchy (for inherited policies)

To add and customize the access summary when creating a configuration, specify the source and destination entity, expand Advanced Options, and pick the Summary Entities you want visible to reviewers. To only return results with paths containing or excluding a specific entity type, use the filter.

Possible entities for the summary depend on the provider and the search mode. For instance, when searching Google User to Google Cloud Project, options include:

• Google Cloud Folder

• Google Cloud IAM Policy

• Google Cloud Role Binding

• Google Cloud Organization

A Google Cloud organization has a hierarchical structure of folders containing projects, which contain individual services. A policy applied at the organization applies to all resources beneath it. Projects and services within a folder likewise inherit policies on that folder. See for more about searching for directly applied policies.

To create a query that returns results with any access, including a summary column indicating where in the resource hierarchy the permissions apply:

1. Create a configuration, and enable System mode

2. Pick the source and destination (Google User to Big Query Table)

3. Expand Advanced Options > Summary Entities

Reviews for this configuration will include a Path Summary column that indicates where a group, policy binding, or role exists in each result's authorization path. Reviewers can click on a role's name to verify the exact resource it is bound to. Reviewers can click an entity name to view more details.

By adding an attribute filter on an entity property such as name, is_active or department, you can create reviews that only contain rows for source, destination, and related entity types with matching attributes. A query might include such filters to scope access review to a (Group name CONTAINS "developers").

When applying an attribute filter on a required related entity, the following behavior applies:

• Attribute filter on Role: only the paths whose Roles meet the constraint appear in the Path Summary column.

• Attribute filter on Group: only the paths whose Groups meet the constraint appear in the Path Summary column.

Overview

Veza Actions enable external processes when decisions and other events occur during an access review. Actions might trigger automated remediation, or announce to a team when a row is rejected, reviewers change, or the review is complete.

For example, you can use Veza to create a Jira issue or ServiceNow ticket for rejected access, or trigger actions in a custom application using a webhook.

To enable Veza Actions for a configuration or review, an administrator will need to configure integrations. See Veza Actions and Custom Webhooks for more information about supported targets.

Configuring Veza Actions

Administrators and operators can add actions when creating or editing a configuration, or by opening the Review Details sidebar in the reviewer's interface. Then, map actions to events they will trigger.

Events that can trigger Veza Actions:

• Reassign reviewer: When a user reassigns a row to another user.

• Approve row: When an approved row is signed off.

• Reject row: When a rejected row is signed off.

• Complete review: When the review is marked "Complete."

Possible actions depend on the event:

• Webhooks: Supports Reassign Reviewer, Approve Row, Reject Row, and Complete Review.

• Microsoft Teams: Supports Reassign Reviewer, Approve Row, Reject Row, and Complete Review. See for detailed setup instructions.

• Email Notifications

When adding a configuration, use the Veza Actions section of the configuration builder to map events to actions in a target system. To enable default actions at the configuration level:

1. Go to Access Reviews> Configurations to create or edit a configuration.

2. In the configuration editor, scroll down to Veza Actions:

3. Toggle events that will trigger actions.

To configure Veza Actions for a 1-step review:

1. Go to Access Reviews > Reviews, or open the review from the Configuration Details page.

2. Click on the review name to open the reviewer's interface.

3. On the Review Details sidebar, find the Veza Actions section and click Configure Veza Actions.

The Revoke access of rejected row on sign-off option in the Veza Actions section enables auto-revocation. When configured, signing off on a rejected row automatically removes the user from the target entitlement — no webhook or custom integration required.

For full details including requirements, supported integrations, and scope constraints, see .

Access review events can trigger a JSON payload sent to an external listener, which parses the payload to trigger remediation actions.

The message from Veza will include the configuration (workflow) and review (certification) name and ID, and the event message or details about the review.

You must configure a service (such as an AWS Lambda function) to read the payload and take action, typically with an API call to the 3rd-party application.

Access review events trigger this JSON payload. The payload includes critical identifiers and names for both the review configuration (workflow) and the specific review (certification), and details about the row and relationship under review.

If available, the response will include the accumulated raw system permissions a source has on a destination, and their equivalent effective permissions.

• details: The payload includes the full entity details for rejected or approved rows, including information about the source node, destination node, and possibly a related intermediate entity.

• Included entity attributes are: canonical_name, datasource_id, id, name, department,

The AwfResult preview API object includes tags and if these options are enabled in the review configuration. Webhook payload details also include these fields:

Tag example:

Enrichment data example:

Overview

When creating an access review, operators can choose to assign the review to entity owners and resource owners as reviewers based on graph metadata:

• Veza can automatically assign reviewers to rows involving entities they own or manage.

• Veza will suggest default reviewers if the review scope is a single named identity or resource with an assigned owner.

• If the identity provider (IdP) used to log in to Veza is added as an integration, you can enable it as a to enable suggestions and auto-assignment for all users in your organization.

To identify a manager, Veza checks the manager attribute (for IdP users), the Entity Owners, or a SYSTEM_resource_managers (on resources) containing a valid user ID. This user ID is defined in the idp_unique_id property on the corresponding IdP User entity in the graph.

Veza auto-assigns reviewers with the following priority:

1. If an entity has an Entity Owner, that owner will be assigned as the reviewer

2. If no Entity Owner is configured on the graph node, Veza will check for a Resource Manager Tag and assign those owners.

3. If a secondary source of identity is configured

See for more details about default and fallback reviewers, and configuration settings.

Access Reviews supports both legacy tag-based manager assignment and Entity Owners. Entity Owners enable simplified manager assignment directly from the Veza UI and improved integration with other products and search features.

In Veza, you can assign Entity Owners directly from Graph search, Query Builder, and the NHI overview page.

For non-human identity (NHI) accounts:

1. Go to the NHI > Accounts overview

2. Select one or more accounts from the list

3. Click the Assign Owner button to open the owners sidebar

Once assigned, entity owners appear in the NHI accounts table's Entity Owner column.

For bulk-assigning owners to multiple entities of different types in Query Builder results:

1. Go to to Access Visibility > Graph > Query Builder

2. Run a query to return the desired entities

3. Select one or more entities from the results

To assign an owner to individual entities in Graph Search:

1. Open Access Visibility > Graph

2. Search for and locate the entity

3. Click on the entity node to open the details sidebar

4. Click the

Entity owners can be assigned to any entity type that includes the owners property in the Veza graph schema. This includes:

OAA application template entities: Application, Users, Groups, Roles, Resources, and Access Credentials. See for details on setting owners in OAA payloads.

IdP application entities: OktaApp, OneLoginApp, AzureADEnterpriseApplication, PingOneApplication, PingOneIdentityProvider, HashicorpVaultAuthMethodSubresource, and CustomIDPApp. Owners for these entity types cannot be set in integration payloads. Assign them using one of the following methods:

• Graph Search or Query Builder: Find the entity and use the Set Entity Owners action in the sidebar, or select multiple entities and click Assign Entity Owners.

• Enrichment rules: Create an of type Assign Entity Owners to automatically assign owners at extraction time.

• Batch Set Owners API: Use the endpoint for programmatic assignment.

The following sections provide information about manager assignments using tags. This is supported as a legacy option, but no longer the recommended approach.

Managers can be identified by a SYSTEM_resource_managers (on resources) containing a valid user ID.

The tag's value is the comma-delineated list of user IDs, for example:

The tag value must match the "IDP Unique ID" property on the user's graph entity for the Global Identity Provider. For Okta, OneLogin, and Microsoft Azure AD identities, this is an email address. If using a , the user or group identity can be any unique string.

You can apply and remove tags programmatically using the . Assign owners "SYSTEM_resource_managers" as the tag key, where the value is a comma-separated list of IdP user IdP Unique IDs.

Add tag:

Remove a tag by providing the entity id and the tag key to delete:

You can update the manager of a Custom IdP User by pushing a new OAA payload or using modify .

To test resource owner assignment using tags:

1. Pick a resource on the graph that doesn't yet have an owner.

2. Apply a system_resource_managers tag with the email address of another Veza user.

3. Create an Access Reviews configuration. Select the entity type of the tagged resource, choose Select a single entity, and specify the resource name.

To test manager assignments using Okta:

1. Pick an IdP entity (such as OktaUser) on the graph.

2. If the user already has a manager, create a corresponding Veza user for the manager's email address (you can give it the Access Reviewer role).

3. Otherwise, log in to Okta and set the user's Manager attribute to your Veza email address.

When using the to submit application and resource metadata, you can assign entity owners via tags (legacy method).

The tagged manager will only be used if no Entity Owner property is present.

You can use to modify or remove tags and properties on OAA entities.

You can use the to create graph entities with metadata for your custom domains, identities, and groups. To assign manager relationships within the custom IdP, users and groups can be mapped to the identity of another user:

To assign an IdP user or group as the manager of any resource Veza has discovered (from another integration), list the node type and node ID in the entities_owned field, for example:

When Veza parses the payload, graph entities are assigned a system_resource_managers tag. The owner(s) will be suggested as reviewers for any reviews when the configuration scope is a single named resource with a matching tag.

Access Reviews help organizations identify and remediate inappropriate entitlements. The Verify Remediations feature automatically reconciles row decisions against live access data on completed and expired reviews:

• Bidirectional auto-validation — the validation job runs in both directions, marking Rejected rows as Fixed when access is removed, and reverting Fixed rows back to Rejected if access reappears.

• Admin override — administrators can manually switch a row's decision between Fixed and Rejected to correct rows that were incorrectly marked.