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.

Reference: Configuration Query Builder

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.

Entity Type Groupings

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

Generic entity type groupings

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

Entity type groupings for custom applications

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 .

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

Key Concepts

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.

Configuring Digest Notifications

To configure Digest Notifications:

1. Navigate to Access Reviews > Settings.

2. Locate the Digest Notifications section.

Enabling Digest Notifications

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

Setting Normal Delivery

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.

Configuring Snooze Days

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.

Configuring Notification Exclusions

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 .

Digest Notification Recipients

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

Customizing digest email content

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

See also

• - Notification system concepts and delivery channels

• - Customize notification content

• - Complete delivery settings reference

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

Add policies during review creation

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.

Review intelligence action logs

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.

Assign policies to some or all configurations

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.

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

Overview

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:

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:

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

Reviewer selection logic

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.

Changing the reviewer selection method

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.

The Veza Customer Success team can change this global setting to enable any of the following selection methods. 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

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.

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.

Overview

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

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

Implementing On-Demand Reviews

Prerequisites

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.

Add a Rule for On-Demand Reviews

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.

Launch Configuration Options

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.

Troubleshooting

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.

Rule Evaluation

• 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

Related Topics

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:

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

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.

Access Reviews Auto-Assignment Logic

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.

Assigning Entity Owners

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.

Assigning Owners on the NHI Accounts 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.

Assigning Owners in Query Builder

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

Assigning Owners in Graph Search

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

Resource Manager Tags

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

Manager Identification with Tags

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.

Assigning resource owners (Tags API)

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 .

Validating manager assignments

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.

Assigning owners for custom applications and identity providers

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.

Assigning managers (Custom IdP)

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:

Assigning owned entities (Custom IdP)

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.

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

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

Question Types

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

Decision-Specific Questions

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

Configuring Predefined Questions

Step 1: Create Question Sets

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.

Step 2: Configure Question Sets in a Review

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)

Reviewer Experience

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:

Making Individual Decisions

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

Bulk Decision Updates

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

Multi-Level Reviews

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

Limitations

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

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

Related Documentation

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 to enable SSO.

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:

Access Reviews settings can be customized to fit the needs of individual organizations and use cases, such as enabling auto-expiration, setting whether all rows need a decision before review completion, or requiring a note with certain decisions. You can also manage how Veza integrates with a corporate identity provider (IdP) to enable single sign-on and least-privilege review flows. See the following sections for more information:

• Suggest reviewers from a global identity provider

• Reviewer auto-assignment

Some of these options must be enabled by the Veza support team, while others can be configured using an API. See for detailed API documentation.

Suggest reviewers from a global identity provider

When selecting reviewers for a new review or re-assigning row-level reviewers, you will choose, by default, from the list of . This includes all local admin, operator, and reviewer root team users. External users from your identity provider are also shown, if they have already logged in with single sign-on and have an appropriate role.

By configuring a global identity provider, you can select reviewers from all users in your organization that Veza has discovered within an integrated IdP, including users who have never logged in to Veza. This eliminates the need to create user accounts for reviewers before they can be assigned to rows.

For example, if your organization's Okta domain is integrated with Veza and single sign-on (SSO) is enabled for your Veza tenant, all the domain's Okta Users will be suggested as possible reviewers. Those employees can then log in to Veza with SSO to complete their assigned reviews.

• To enable a global Access Reviews Identity Provider, see . Enabling a global identity provider also enables reviewer auto assignment to .

• If notifications are enabled for a configuration or review, any new reviewers are notified by email, with a link to log in and make decisions on their assigned rows.

• When using a global identity provider, it may be preferable for external users to have the Reviewer role assigned by default, preventing unauthorized access to other Veza functionality. You can change the default role under

Reviewer auto-assignment

You can choose to auto-assign managers and resource owners when creating a review or re-assigning reviewers. Any rows in the review that cannot be auto-assigned are assigned to fallback reviewer(s).

To enable Veza to automatically identify managers and resource owners, see :

• Within your IdP, set the corresponding manager property on the user object

• Within Veza, add a Veza Tag that identifies a resource owner.

When an integrated Identity Provider (IdP) is configured as the global identity provider, these managers and resource owners can sign in to Veza without first needing to create an account.

Self-review prevention

You may want to prevent reviewers from being able to review and sign off on their own access in a review. When self-reivew prevention is enabled and a Global IdP is configured, users cannot be assigned to review rows for identities that match their global unique ID:

• Users with an ID that correlates to a review row cannot be assigned as reviewers for that row: "" cannot be assigned as a reviewer for any row in a review involving Okta User "."

• Users cannot be assigned to review access for local user accounts for which they're the top-level identity (if Veza has detected a correlation between an IdP User with id [email protected] and the local Snowflake User jsmith, IdP User won't be allowed to be a reviewer for any rows that involve his local Snowflake User account jsmith.

Self-review prevention can be enabled or disabled via . Possible settings are:

• SELF_REVIEWER_CHECKING_DISABLED (default)

• SELF_REVIEWER_CHECKING_ENABLED

Self-review prevention with auto-assignment

When auto-assigning reviewers, operators can specify a list of fallback reviewers. These users are assigned when self-review rules or the deny list would prevent the original assignment. They are also used when a manager or owner can’t be found.

If a fallback reviewer is prevented from reviewing their own access or is on the deny list, the other fallback reviewers are assigned to the row.

If there are no fallback reviewers and a rule prevents an assignment, Veza will select a reviewer in the following order:

1. The blocked user’s manager or resource owner (if not explicitly inactive)

2. The configuration creator

3. A Veza system administrator.

See to customize this behavior.

Review completion settings

Depending on how your organization conducts access reviews, you may prefer that users be able to complete reviews at any point, or want reviews to autocomplete when certain requirements are met.

Autocompletion

By default, a review must be manually marked "complete" once a reviewer has signed off on all decisions. This setting can be changed so that reviews move are considered complete once a reviewer signs off on the final row. You can also customize autocomplete behavior to allow or prevent autocompletion of reviews that contain "Rejected" decisions.

This behavior is customizable using an .

Example request:

Possible values are

• COMPLETION_ALLOWED_ALL_ROWS_HAVE_DECISION (default): Once all rows have a decision, the review will be automatically marked as complete and no further changes can be made.

• COMPLETION_ALLOWED_ANYTIME Any reviewer can click Complete to finish and close the review at any point.

• COMPLETION_ALLOWED_ALL_ROWS_HAVE_NON_REJECT_DECISION

Auto Complete Settings determine whether reviews automatically move to "completed" status once the deadline is passed. Possible values are:

• AUTO_COMPLETE_DISABLED (default)

• AUTO_COMPLETE_ENABLED

Example request:

Enable or disable review expiration

When enabled, all reviews will move to the EXPIRED status and become read-only once 24 hours have passed since the due date. Possible values are true or false (default). This behavior is customizable using an .

Requiring notes with decisions

By default, adding a note is optional when making decisions on rows. However, you may prefer that reviewers be required to leave a note under certain conditions. For example, you could require a note for rejected rows, while prompting (but not requiring) a note for approved rows.

Notes pop-up behavior sets whether the "Notes" modal appears and if a note is required when making decisions on rows. "Approve" and "Reject" behavior can be customized separately:

• Approved notes behavior:

  • No pop-up

  • Optional (default)

This behavior is customizable using an .

Example request:

When "No pop up" is selected, no prompt is shown, and notes must be added by clicking Add Note. Otherwise, a note will be required or optional depending on the decision.

Change default columns and sorting

An administrator can customize row sort order and the default columns shown in reviewer interface. Columns can be customized globally and per configuration. New reviews will use the default columns for the parent configuration.

Administrators can also control column visibility based on user roles. The hide_from_reviewers_columns setting allows specific columns to be hidden from users with the reviewer role while remaining visible to administrators and operators. This is useful for hiding sensitive information like internal identifiers or technical details that should not be exposed to all reviewers.

See for more information about the possible columns and API documentation.

The following example sets global default columns based on the source, destination node, and intermediate (waypoint) node properties, and shows each row's reviewers. It also hides sensitive columns from reviewers while keeping them visible to administrators:

The default sort value is source.type asc, and can be configured using an .

Example sort setting:

Review row grouping

Administrators can configure how review rows are grouped to help reviewers process large datasets more efficiently. When enabled, rows are automatically organized by column values such as resource name, identity name, or review status, making it easier to review related items together.

Enabling this setting globally and for specific use cases can support faster review completion, help users identify patterns across similar items, and focus on single groups at a time for reduced cognitive load.

Row grouping can be configured Globally (establishing the default for all new reviews) or Per Review Configuration (overriding the global default for specific review types). Common options for grouping include:

• By resource (destination.veza_unique_name): Review all access to each resource together

• By identity (source.veza_unique_name): Review all of a user's access at once

• By status (status

For detailed API documentation and examples, see .

Outlier detection

Administrators can configure outlier detection to automatically identify anomalous access patterns in Access Reviews. The system compares each user's access to a peer group (by default, users sharing the same manager) and flags access held by fewer than a specified threshold percentage of peers.

By default, outlier detection groups users by their manager (manager_idp_unique_id property) and flags access held by ≤15% of peers as outliers. This helps reviewers focus on unusual or potentially risky permissions.

Key benefits:

• Risk prioritization: Automatically highlight potentially risky or unusual access patterns

• Efficiency: Help reviewers focus on anomalous access rather than reviewing normal permissions

• Contextual analysis: Compare access within relevant peer groups rather than across the entire organization

Outlier detection can be configured globally (establishing the default for all new reviews) or per review configuration (overriding the global default for specific review types).

Common configurations:

• By manager (default): Flag access rare among direct reports to the same manager

• By department: Flag access rare within the same department

• By department + location: Flag access rare among users in the same department and office

For detailed API documentation, configuration examples, and use cases, see .

Customize reminder and notification emails

Emails sent by Veza can include instructions, unique branding, and placeholders for metadata specific to the review. See to customize notification emails sent to reviewers and other stakeholders.

• A template can be set for each potential usage (review created, row assigned, due date reminders, and others).

• Placeholders can be used to include direct links to the review, dates, and reviewer metadata such as Name, depending on the selected usage.

• Custom HTML/CSS can be included in a base64-encoded body template.

See for preview API usage details.

Notification exclusions

Administrators can configure label-based exclusions to prevent specific Access Reviews from generating notifications. Exclusions can be configured independently for:

• Digest Notifications: Exclude reviews from periodic digest emails

• Alerts: Exclude reviews from immediate notifications when reviewers are assigned

For configuration instructions, see .

Review interface presentation rules

To enable easier identification of potentially dangerous results, Veza supports custom styling rules to highlight disabled (inactive) users. In addition to these rows appearing in red during review, the text summary shown when hovering the row will indicate that the user is inactive.

Please contact your Veza customer success team to enable this option. To highlight results based on a custom presentation rule, provide:

• The filter string to use (for example source.is_active eq false). The property to match can be on the source or destination entity types in the configured query.

• (Optional) a list of review ids the presentation rule will apply to (affecting all reviews on that configuration). Otherwise, rules apply to all reviews.

Reviewer export permissions

Organizations may need to control whether reviewers can export access review data based on security policies or compliance requirements. Veza provides granular control over export formats, allowing administrators to enable CSV exports while disabling PDF exports, or vice versa.

When export features are enabled, users with the reviewer role can download review data in the allowed formats for offline analysis and reporting, record-keeping, and integration with external tools and workflows.

When export features are disabled, the corresponding functionality is removed from the reviewer interface. This helps prevent unauthorized data exfiltration while allowing controlled exports.

By default, CSV, PDF, and XLSX (Excel) exports are disabled for enhanced security. Administrators must explicitly enable export capabilities as needed.

This behavior is customizable using an . The setting can be configured globally for all reviews or for specific review configurations.

Example request to disable all exports (default):

Example request to enable only CSV exports for a specific review configuration:

Mandatory due dates

Organizations may require that all access reviews have a due date set to ensure timely completion and compliance with internal policies. When mandatory due dates are enabled, review creators must specify a due date before creating a review.

This setting can be configured:

• Globally: Applies to all new reviews by default

• Per Review Configuration: Override the global setting for reviews created from a specific configuration

The setting supports multi-level reviews, allowing different requirements for each approval level:

• mandatory_for_first_level: Require due date for primary reviews

• mandatory_for_second_level: Require due date for second-level reviews

• mandatory_for_third_level: Require due date for third-level reviews

This behavior is customizable using an .

Example request to require due dates for first-level reviews:

Example request to configure a specific review configuration:

Saved filters

Administrators can add preset filters for users to choose from. Quick filters can be accessed under the Filters menu in the reviewer interface. When creating a saved filter, you can enable it for all reviews or just one.

See for more information about adding pre-built filters.

Overview

Veza's Slack App integration sends direct message notifications to users assigned access reviews. Unlike , which posts messages to connected Slack channels, this integration delivers notifications directly to users via the Veza Slackbot.

Comparison with Slack Webhook Integration

This integration complements the prior webhook-based Slack integration with the Veza platform. Both the Veza Slackbot and webhook-based integration with Slack can be used in tandem for both channel announcements and direct messages to reviewers:

The Veza Slackbot requires dual-step authentication:

1. A Veza Slackbot User OAuth Token (xoxb-...) from your Slack app installation allows Veza to send direct messages to users, look up users by email address, and test the connection to your workspace.

2. When Slack users first connect to the Veza Slackbot, they authenticate through Veza's login system (using SSO or a local login), creating a persistent identity mapping between their Slack user ID and Veza account.

The user connection flow uses PKCE (Proof Key for Code Exchange) for added security.

Prerequisites

• Admin access to your Slack workspace

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

• Feature flag UI_SLACK_APP_INTEGRATION enabled (contact Veza support to enable)

Network Requirements

The integration requires inbound connectivity to your Veza tenant:

How User Matching Works

User email addresses in Slack must exactly match the reviewer's email address in Veza for proper notification flow. The Veza Slackbot matches users between Veza and Slack using the following process:

1. Veza identifies the reviewer. This is the user assigned to a review in Veza Access Reviews.

2. Email lookup - Veza takes the user's email address from their Veza account

3. Slack user search - The integration calls Slack's API (GetUserByEmail) to find a user with that exact email address

First-Time User Connection

When a Slack user receives their first notification from Veza, they may need to connect their Slack account to their Veza account:

1. If Veza hasn't previously linked the Slack user ID to a Veza account, the notification includes a "Connect" button

2. Clicking "Connect" redirects the user to Veza's standard login page

3. The user logs in with their existing Veza credentials (local account or SSO, depending on your configuration)

Known Limitations

• No digest notifications: Currently, each notification is sent individually. Digest or summary notifications are not yet supported.

• No customizable templates: Notification message templates are not customizable at this time. All users receive the same message format.

• Email matching required: Users must have matching email addresses in both Veza and Slack for notifications to work

Create the Veza Slack App

Using the App Manifest (Recommended)

1. Go to and click Create New App

2. Select "From an app manifest"

3. Choose your workspace

Gather Required Credentials

After installation, collect these values:

1. Basic Information > App Credentials:

   • Client ID

   • Client Secret

Configure in Veza

1. Navigate to Integrations > Veza Actions

2. Click Create Veza Action and select Slack App

3. Provide the required information:

Using Slack App in Access Reviews

Configure Notification Settings

When creating or editing an Access Review:

1. Go to Notification Settings

2. Under Delivery options, select Slack App

3. Choose your configured Slack app from the dropdown

What Users See

With the Veza Slackbot, users may periodically receive notifications about new reviews coordinated by your organization using the Veza platform. These reviews may require immediate participation. From these notification messages, you can easily access the Veza Access Hub to review and quickly complete any assigned access reviews.

Access Review Notifications

Reviewers receive direct messages like:

The View in Veza button opens the review directly in their browser.

Additional Resources

• - Channel-based notifications

• - Access Review setup guide

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). The value in this attribute must match the value of the main IdP's user_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.

The lookup settings configuration includes:

• 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.,

Order matters when configuring more than one alternate source of identity. Veza will check the primary IdP first, then the first alternate lookup, then the second, and so on, until a manager is found or all options are exhausted.

Notes:

• For reviews initiated using the main IdP (e.g., Okta), the system will look up managers from alternate sources (e.g., Oracle HCM).

• The system will also try alternate lookup methods if the primary lookup fails.

• The manager identity property can contain a single value or a list of values.

Manager Lookup Process Flow

API Configuration

Currently, identity providers for review auto-assignment are managed using 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

For example:

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.

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.

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.

Lifecycle Management Auto-Revocation

Access Reviews integrate with Lifecycle Management for auto-revocation. When access is rejected during user access review, Veza Lifecycle Management can revoke a user's group membership automatically. For example, if the scope is Active Directory user to Active Directory security group, a lifecycle management workflow can remove a user from the group described in a rejected row.

Benefits:

• Revoke users from groups, roles, profiles, and permission sets automatically on reject.

• Supports all target apps supported by Lifecycle Management

• No custom integration - no webhooks

Requirements:

• Lifecycle Management and Access Plans must be enabled for your tenant.

• The Lifecycle Management integration for the target application must have permissions to remove roles, group membership, or otherwise manage relationships for users.

Implementation Considerations:

• The Revoke access on Sign-off of Rejected Rows action appears in Veza Actions for Configurations with supported source and destination pairs.

• Reviews must be structured with users as the source and the destination being roles, groups, or permission sets within the same target application.

• Auto-revocation does not support source-only Reviews.

Webhook payload

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.

Example webhook: review completed

Example webhook: rejected row

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, email