Change the columns shown in the reviewer interface, and the order rows appear.
Overview
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.
Column Pinning and Reordering: Reviewers can drag column headers to reorder them, or pin columns to keep them visible while scrolling. These customizations are saved to your browser and persist across sessions.
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:
From the reviewer interface (UI): Administrators can set default columns and grouping directly from the review UI. This is the quickest way to configure defaults for a specific configuration.
Using the API: Use API calls to set defaults globally or per configuration. This approach is ideal for automation or bulk changes.
Setting default columns from the UI
Administrators can configure default columns for all reviewers using a specific configuration directly from the reviewer interface:
Open a review created from the target configuration in the reviewer interface.
Arrange columns to your preferred layout (show, hide, and reorder columns as needed).
Optionally, select a Group By option to set a default row grouping.
The selected column layout and grouping option will be applied as the default for all future reviews created from this configuration. Existing reviews are not affected.
The Set Columns as Default option saves both the column layout and any active row grouping selection. For more details on row grouping, see .
Setting default columns using the API
Column customizations can also be configured using a private API call. This method is useful for setting global defaults, automating configuration, or making bulk changes across multiple configurations. By default, the customization applies to all reviews. Optionally, it will apply to all reviews created for a given workflow_id (corresponding to a review configuration in Veza).
The following example sets per-workflow default columns, including source tags, custom properties, summary entities, and reviewers:
Sort order
The default sort value is source.type asc for ascending order. You can default to descending order or sorting on another column by including an order_by value, for example:
waypoint.attribute_name: Attributes on the Relationship entity, if specified in the configuration.
Columns can also show row metadata:
status
abstract_permissions
concrete_permissions
Alternate Manager Lookup
How to configure and use alternate manager lookups for access review auto-assignment.
Overview
Alternate manager lookups provide enhanced review auto-assignment by allowing Veza to identify managers from multiple sources of identity metadata. This is particularly useful if your organization has complex identity structures with more than one identity provider (IdP).
You may need to configure an alternate identity provider for manager assignments to enable:
Automatic manager assignment for contractors tracked in a separate IdP (e.g., a custom OAA IdP) with managers from a primary IdP (e.g., Okta).
Auto-assigning access reviews involving users in the main IdP (e.g., Okta Users), when manager information is maintained in another system (e.g., Oracle HCM).
By supporting cross-source manager lookups, Veza ensures consistent and accurate access review assignments, regardless of where user or manager identities are maintained.
Example Implementation
Alternate lookups are intended for situations where you have a primary identity provider and additional sources of identity in another system. For example, you might import identity data for contractors via a custom CSV, and want to have their access reviewed by managers who are Okta users. In this case, you want to ensure that:
Contractor access reviews are assigned to their actual managers (who are Okta users).
Even if the contractor identity lacks a direct manager attribute in the custom IdP, Veza can still identify the correct manager from Okta.
With an alternate manager lookup, you can configure Okta as a primary IdP, and a the imported CSV provider as the secondary IdP. When a contractor's access is reviewed, the system will first check if they have a linked user in Okta. If no linked user or manager is found, it uses the alternate lookup settings to find the appropriate manager in Okta.
How It Works
When creating an Access Review, administrators can choose to auto-assign rows to individual managers. Veza will identify managers using one or more identity providers.
For auto-assignment to function:
Users in the review must be linked to an identity, either in the main IdP, or one of the alternate lookups. This connection is made based on the attribute mapping in your Global IdP settings.
The connected identities must have an attribute that contains one or more identifiers used to look up each user's manager(s). The attribute could be managers or any other attribute configured in your settings (manager_identity_property). 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:
Primary IdP Lookup: The default method uses the main (e.g., Okta) to find managers based on configured manager properties.
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., customprop_manager_employee_number
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:
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:
Click Admin > Set Columns as Default.
path_summary.name: Shows Summary Entities from the configured scope.
idp.attribute_name: Attributes on the related IdP or HRIS user for a row, when the Enrich option is enabled for the configuration.
Require multiple levels of approval before access review decisions are final.
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:
First-Level Review: The initial review phase where primary reviewers make decisions.
Second-Level Review: The final review phase where secondary approvers act after all rows have first-level decisions.
Sequential Approval: The first-level review must be completed before moving to the second level.
Decision Models: Configurable rules that determine how decisions are evaluated across review levels (see below).
Decision Models
Access Reviews support different decision models that determine how multi-reviewer decisions are evaluated at each level. You configure the decision model in the Multi-level Reviews step when creating or editing a review configuration.
To configure a decision model:
Go to Access Reviews > Configurations and create or edit a review configuration.
Navigate to the Multi-level Reviews step in the configuration wizard.
Select one of the following decision models:
Unanimous Approval: All reviewers at a level must approve for the row to be approved. A single rejection results in rejection.
Unanimous Rejection: All reviewers at a level must reject for the row to be rejected. A single approval results in approval. When configured with this model, the review automatically advances to the next level or completes once all reviewers at the current level have made their decisions.
Last Decision: The decision made by the final reviewer at each level determines the outcome for that level.
When using the Unanimous Rejection decision model in multi-level reviews, ensure that all reviewers at Level 2 complete their decisions for the review to properly advance. The system evaluates the decision model at each level independently.
Auto Advance Level at Due Date
You can configure multi-level reviews to automatically advance to the next level when the current level's due date is reached, even if some rows remain undecided. This prevents reviews from stalling when reviewers don't complete their decisions in time.
To enable auto-advance:
In the Multi-level Reviews step of the configuration wizard, enable the Auto advance level at due date toggle.
Select the default decision for undecided rows:
Approve: Automatically approve undecided rows when advancing
When auto-advance is enabled, undecided rows will receive automatic decisions at the due date. Ensure reviewers are aware of this behavior to avoid unintended approvals or rejections.
Multi-Level Review Process
Multi-level reviews allow organizations to optionally configure reviews that require multiple parties to review rows of access and sign off sequentially to complete the review. For instance, the first level of review may be performed by a user's manager while the subsequent second level of review is completed by the application owner.
First-Level Review
Starts upon creation of a multi-level review.
First-level reviewers can see and act on all assigned rows.
How first-level decisions affect second-level visibility depends on your configured decision model. With Unanimous Approval, rejected rows are final and hidden from second-level reviewers. With Unanimous Rejection or Last Decision, second-level reviewers may see and act on rows regardless of first-level decisions.
Notifications Behaviors for Reviewers in Multi-Level Reviews
For typical reviews with one level of reviewer, all reviewers may receive when the review is started. Inactivity reminders also go only to all reviewers. Notifications of any type are only sent if they are explicitly configured.
The following rules apply with second-level review enabled:
If configured, review start notifications are sent to first-level reviewers.
Second-level reviewers are notified when their review phase begins.
If configured, reminders are sent only to reviewers at the current level.
Veza Actions in Multi-Level Reviews
Multi-level reviews can include to trigger actions such as sending emails, creating service desk tickets, or activating webhooks for revoking access.
Veza Actions configured for when rejected rows are signed off will trigger at the first level that the rejection decision is made and signed-off. This could be the first- or second-level of the review.
Veza Actions for approved rows only trigger when a row is signed off in the second and final approval level.
Enabling and Assigning Second-Level Reviewers
You can assign second-level reviewers explicitly (by username or email) or through auto-assignment. In addition to auto-assigning the manager of a source user or the owner of a destination resource, second-level reviews can be assigned to the manager of each first-level reviewer using information from your identity provider.
To enable and assign second-level reviewers:
Go to Access Reviews > Configurations and click New Review to create an access review.
Define the scope, set a due date, and assign initial reviewers.
In the Second Level Reviewers section, click Enable.
See and for more information about assigning reviewers, auto-assignment, and fallback behavior. Auto-assignment requires that an integrated identity provider is set as the .
Multi-Level Approval in the Reviewer Interface
This feature is not enabled by default and is controlled by a feature flag. Please contact Veza Support to enable multi-level reviews in your environment.
In the reviewer interface, an information bar above the rows shows whether the review is in the first or second approval level. A progress bar displays the status of rows (approved, rejected, or without decisions) at the current level.
Users with an Operator or Administrator role can view all rows at the current review level. Users with the Access Reviewer role can only view and update their assigned rows in their review level.
Otherwise, the review interface remains identical compared to typical single-level reviews. Reviewers inspect each row, reassign reviewers, add notes, and make decisions. You can add to inform users about your specific guidelines for multi-level approvals.
FAQs
What happens if a row is rejected at the first level? This depends on the decision model. With Unanimous Approval, the row is considered rejected and hidden from second-level review. With Unanimous Rejection or Last Decision, second-level reviewers can still see and potentially override the decision.
Can a first-level reviewer view or change their decisions on a review after they have signed off on the review and it has proceeded to second-level review? No.
Can second-level reviewers see first-level reviewers' comments? Yes, comments and annotations are visible to second-level reviewers, enabling communication between review levels.
Entity Owners and Resource Manager Tags
How to automatically assign reviewers using your Identity Provider, Graph Search, or Veza APIs.
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.
Access Reviews Query Builder
Reference for the review configurations query builder.
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.
Identity Provider and HRIS Enrichment
Create access reviews to include information from an integrated identity provider or human resource information system.
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.
Reject: Automatically reject undecided rows when advancing
Do nothing: Leave rows undecided (only available with the Last Decision model)
Optionally customize the message that will be added to auto-decided rows.
All rows must be signed off before the review progresses to the second level.
Second-Level Review
Begins after first-level reviews are complete.
Second-level reviewers see rows based on the configured decision model and first-level decisions.
If configured, completion notifications are sent to all reviewers.
Assign specific reviewers, or auto-assign the user's manager, the resource's owner, or the first-level reviewer's manager.
Click Create and Publish to start the review (notifying reviewers), or Create to save it as a draft.
Can I adjust the timeline for completing first and second-level reviews? Both levels of the review must be completed by the due date set when the review is created. If Auto advance level at due date is enabled, undecided rows will receive automatic decisions (approve, reject, or do nothing) based on your configuration. Otherwise, the review may expire depending on the Global Settings. Ensure prompt first-level reviews to allow time for second-level decisions.
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 Global Identity Provider 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_managerstag (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:
If an entity has an Entity Owner, that owner will be assigned as the reviewer
If no Entity Owner is configured on the graph node, Veza will check for a Resource Manager Tag and assign those owners.
See Reviewer Selection Logic 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:
Go to the NHI > Accounts overview
Select one or more accounts from the list
Click the Assign Owner button to open the owners sidebar
Search for a user by name or email
Confirm the assignment
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:
Go to to Access Visibility > Graph > Query Builder
Run a query to return the desired entities
Select one or more entities from the results
Click the Assign Entity Owners button at the top of the results
Search for and select the appropriate owner(s)
Confirm the assignment
Assigning Owners in Graph Search
To assign an owner to individual entities in Graph Search:
Open Access Visibility > Graph
Search for and locate the entity
Click on the entity node to open the details sidebar
Click the Set Entity Owners option in the sidebar
Select the appropriate owner(s) and save your changes
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.
Tag persistence:SYSTEM_resource_managers tags can be lost if a provider, datasource, or specific entity is removed and recreated. If you rely on these tags for reviewer auto-assignment, be aware that removing and re-adding a provider or datasource will require you to reapply the tags. Export your tag assignments before making such changes. See Tag persistence for more details.
Note that Entity Owners assigned via the UI or API are also lost when entities are removed and recreated, as owner data is stored directly on entity nodes.
Manager Identification with Tags
Managers can be identified by a SYSTEM_resource_managerstag (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 custom IdP, the user or group identity can be any unique string.
Assigning resource owners (Tags API)
You can apply and remove tags programmatically using the Tags API. 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 modifyincremental updates.
Validating manager assignments
To test resource owner assignment using tags:
Pick a resource on the graph that doesn't yet have an owner.
Apply a system_resource_managers tag with the email address of another Veza user.
Create an Access Reviews configuration. Select the entity type of the tagged resource, choose Select a single entity, and specify the resource name.
Save the configuration and create a review.
The resource owner's Veza account should be selected as the default reviewer.
To test manager assignments using Okta:
Pick an IdP entity (such as OktaUser) on the graph.
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).
Otherwise, log in to Okta and set the user's Manager attribute to your Veza email address.
Create a configuration. Select the entity type (OktaUser) and choose to Select a single entity. Enter the Okta user name.
Save the configuration and start a review.
The manager's Veza account will be a suggested default reviewer.
Assigning owners for custom applications and identity providers
When using the custom application template 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 Incremental Updates to modify or remove tags and properties on OAA entities.
Assigning managers (Custom IdP)
You can use the custom identity provider template 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.
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.
Scope Options
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.
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.
Field
Description
Name
A friendly name for the configuration, used for notification messages and shown on the Access Reviews page.
Description
Used to add internal notes, such as details about the configuration scope and purpose.
Query Mode: Effective
When enabled, returns effective permission calculations for the source and destination pair.
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.
All Local Users: Entities with the LocalUser label (e.g., Google Cloud SQL User, Hashicorp Vault Alias, or MongoDB Users)
All Resources: All entities with the Resource label.
AccessCreds: Entities with the AccessCreds label.
You can check which entities are included in an entity type grouping using the query builder. Search for the label in Access Visibility > Query Builder and review the list of included entities in the Filter By Type dropdown menu.
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 Roles
Custom Role Assignments
Custom IdP Domains
Custom IdP Groups
Custom IdP Users
Custom Groups
Custom Permissions
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 OAA Templates.
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:
Create or edit a configuration.
In the review scope, enable Advanced Options > Enrich with IdP/HRIS data.
Select from the list of supported entity types to enable result enrichment (such as "Workday Worker" for "Okta User"):
Choosing an entity type for enrichment.
Save the configuration and create a review.
In the reviewer interface, use the column selector to enable columns for the "IDP User."
To configure the reviewer interface to show these columns by default, see .
Filters on IDP/HRIS Enrichment
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:
Okta User
Local User
Local Group
Bob
Bob
Group1
Bob
Bob
Group2
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:
Okta User
Local User
Local Group
Bob
Bob
Group1
Bob
Bob
Group2
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.
Missing Enrichment Data
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:
Confirm the HRIS or IdP integration has completed a successful extraction.
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).
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.
Using Enrichment Data in Automations
When you enable IdP/HRIS enrichment for an Access Review configuration, the enriched entity data is available for use in Intelligent Automations. This enables automation scenarios such as automatically rejecting access for users without a matching identity provider profile.
Early Access: Using enrichment data in Automation filters is currently in early access. The API validation may reject some filter expressions involving enriched entity aliases. Basic filters on source.* and destination.* attributes are fully supported in Automations. Contact Veza Support for the latest status on this feature.
Understanding Enrichment Aliases
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.
Important: When referencing enriched entity attributes in automation filters, use the alias directly (e.g., idp.department). Do not use joined_nodes.idp.department. The joined_nodes prefix appears in result data but is not valid in filter syntax.
Finding the Alias for Your Configuration
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:
Check API responses (recommended): Call the List Certifications endpoint for your workflow. The response includes the query_spec with join_connected_specs that shows the as field value for each enrichment.
Inspect browser network responses: When viewing a review in the Veza UI, open browser developer tools (F12) and examine the network responses. Look for:
The query_spec object containing join_connected_specs with as field values
The joined_nodes map in result data, where the keys are the aliases
The Query Builder UI displays friendly names (e.g., "Okta User") in column headers. The underlying alias can differ. Always verify the actual alias from the API or network responses before writing Automation filters.
Automation Filter Examples
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.
Automation filters use SCIM syntax, which does not support regular expressions. Use sw (starts with), ew (ends with), or co (contains) for partial string matching.
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:
Example: Auto-Reject Orphaned Accounts
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.
For complete documentation on creating and managing Automations via the API, see Automations API.
Optional IDP User columns in the reviewer interface.
idp.idp_unique_id pr
not (idp.idp_unique_id pr)
hris.department eq "Engineering"
source.identity_type eq "HUMAN" and not (idp.idp_unique_id pr)
(source.customprop_attr_code eq "100" or source.customprop_attr_code eq "200") and not (idp.idp_unique_id pr)
{
"name": "Reject Orphaned Human Accounts",
"description": "Auto-reject local human accounts with no associated IdP profile",
"priority": 1,
"attachment_behavior": {
"attach_to_new_workflows": true,
"opt_in": true
},
"criteria": {
"filter": "source.identity_type eq \"HUMAN\" and not (idp.idp_unique_id pr)"
},
"action": {
"decision": "REJECTED",
"signed_off_state": "UNKNOWN_SIGNED_OFF",
"notes": "Local user has no IdP profile"
}
}
Configuring a Global Identity Provider
Integrating with an Identity Provider enables single sign on and auto-assignment for Access Reviews.
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.
Before you start
The Access Graph must contain entities for an integrated provider data source. See the integration guides for:
Retrieving the auth_provider_id
Important: The auth_provider_id in your IdP settings must match the id field from /api/private/auth_providers for your SSO provider type. Using a mismatched auth provider ID will cause duplicate users to appear in Access Reviews—both the local user and the graph user will be shown when only the graph user should appear.
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:
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:
Enable Veza to suggest reviewers from the graph by specifying the SSO auth_provider_id and identity provider data source instance_id:
Value to update
Description
`user_identity_property` should be a globally unique value. Setting this to a name or email should be avoided as a best practice.
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.
Examples
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:
SSO External ID Integration
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.
Validating global identity provider settings
Test your configuration by creating a review and selecting reviewers:
If the user_type, instance_id, and instance_id_property are correct, identities from the graph will appear in the suggestions.
If auth_provider_id is correct, SSO users should only appear once in the scenario above. The local user entry is filtered from the list. Only the user record from the graph entity will appear.
Testing SSO External ID Integration
When SSO external ID is configured, you can verify the precedence hierarchy and fallback behavior:
Precedence Verification: Create a test user with both email and external ID values in your SSO provider. When this user authenticates to Veza and appears in reviewer assignment, the system will use their external ID for Access Reviews user matching, taking priority over email-based matching.
Fallback Testing: Configure a test user with email but no external ID value in your SSO provider claims. This user should still authenticate successfully and be available for reviewer assignment, demonstrating that missing external ID values automatically fall back to email-based matching without authentication failures.
Configuration Alignment: Verify that the external ID values from your SSO provider match the data in your user_identity_property field for graph entities. Users should be consistently matched between SSO authentication and reviewer assignment, enabling reliable auto-assignment features even when email addresses are not unique in your SSO provider.
Expected behavior when configured correctly:
Identities from the graph appear in reviewer suggestions (validates user_type, instance_id, instance_id_property)
Each SSO user appears only once as their graph entity (validates auth_provider_id)
If you see duplicate users (both local user and graph user for the same person):
The auth_provider_id does not match your SSO provider's ID
Retrieve the correct value from /api/private/auth_providers and update your configuration
Review Intelligence Policies
Accelerate Access Reviews by rejecting or approving results with specific attributes or with prior decision data.
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.
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.
Create a configuration or search for an existing one on the Access Reviews page.
Start or schedule a review for the configuration and enable automation by clicking Use Review Intelligence Policies.
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.
Query Mode: System
When enabled, returns system-level entities and raw permissions for the source and destination pair.
Source Entity Type
Selects the entities to review (typically an identity). The results will include all entities of the chosen type.
Destination Entity Type
Usually, one or more types of resources to approve an identity's permissions on. However, any entity can be the final node of the path (such as a role, service, or group). Rows will show source entities and their relationships to entities of the chosen type.
Select a single entity (Optional)
When selected, only show access involving a specific source or destination entity, specified by name.
Preview source/destination entities
Update the results table to preview source or destination entities based on Veza's most recent graph data. Reviewers will certify the query results based on graph data at the time of review creation.
Advanced Options: Include source tags in review results
When enabled, reviews include a column showing the keys of any tags on the source entity.
Advanced Options: Include destination tags in review results
When enabled, reviews include a column showing tag keys for the destination entity.
Advanced Options: Relationship
Enables optional columns for reviewers, showing the full entity metadata when an entity of the selected type exists in the path between the source and destination (such as the group granting an Okta user access to an app).
Advanced Options: Summary Entities
The review will include a column indicating the names and hierarchical relationships of the specified entity types.
Advanced Options: Exclude Entities
Exclude results with a relationship to the selected intermediate entity type(s), for example, to review users not assigned to groups.
Advanced Options: Require Entities
Only show results that have a relationship to the required entity type(s), such as users directly assigned to groups.
Relationship Options: Include Assumed
By default, reviews contain a row for each unique source-destination relationship, including assignments that are due to nested groups, roles, or projects. Disable this option to only include rows for the top-level assignment.
Advanced Options: Relationship
An intermediate entity category to require, such as a local user account, group, or role. When specified, details on this intermediate node appear in an additional review column.
Filter by an entity property, such as user department. Click + Add Predefined Attribute Filter to quickly add a filter on the user "manager" attribute, when the source user is the same as the user entity type defined in Access Reviews Global IdP Settings.
Filters: Tags
Only return results that include (or don’t include) the specified tags. Tags can be Veza Tags, or discovered tags native to an integration, such as AWS Tags or Snowflake Tags. Enabling Show Source/Destination Tags will additionally provide reviewers with the ability to see any tags applied to the results, and sort and filter by tags within the review interface.
Filters: Permissions
Only return results with specific privileges on the destination resource. Permissions can be effective or system. Based on the operator, matches can be "all" or "any". Applying a permissions filter to a query that does not involve permissions (such as User to Role) will return no results.
Restrict which users can delete In Progress reviews or modify their due dates, independent of their assigned Veza role.
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.
The allow list is configured using the API. There is no UI for managing the list itself.
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.
Role Requirements
Operation
Required Role
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.
Enable the Action Allow List
To check the current state:
Returns {"enabled": true} or {"enabled": false}.
To enable:
To disable:
Add Users and Groups to the Allow List
The endpoint for managing list entries (/api/private/workflows/access/action_allowlist) is different from the settings endpoint used to enable or disable the allow list (/api/private/workflows/access/settings/action_allowlist_enabled). Sending a principals payload to the settings endpoint will not add entries to the list.
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:
API Reference
For the complete API reference including request and response schemas, see .
Predefined Question Sets
Configure required questions and answers for access review decisions to enrich the decision context and meet compliance requirements.
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:
Multiple Choice: Present predefined answer options. Answers appear in the configured order, and can include an "Other" option for free-form text response
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.
Navigate to Access Reviews > Settings > Question Sets (requires Admin or Access Review Admin role)
Click Create Question Set
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:
In the configuration builder, navigate to the Predefined Questions step
For On Accept, select a Question Set from the dropdown (optional)
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:
Upon clicking Approve or Reject, a dialog appears with the configured questions
Questions are displayed in their configured order
The reviewer must answer all questions
Bulk Decision Updates
When decisioning multiple rows at once:
One set of questions appears for all selected rows
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:
First Level: Reviewers answer questions when making decisions
Propagation: When decisions move to the next level, question responses are automatically copied
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
Reviewer Selection Methods
Configuring fallback behavior for reviewer auto-assignments.
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
Early Access Feature: The Alternate Reviewer Settings API is currently in Early Access as part of the private API namespace. Contact your Veza Customer Success Manager for assistance with this configuration.
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:
Assign the denied candidate's User Manager (if allowed).
Otherwise, assign the first valid Fallback reviewer.
Assign no reviewers for results where a valid manager or fallback reviewer does not exist.
1-Step Access Reviews
Configure a new access review using the quick builder.
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:
Pre-defined scopes for common scenarios and applications such as Okta, AWS, and Salesforce.
A saved query, either built-in or constructed using the query builder.
Creating a 1-step review
When 1-step reviews are enabled, administrators and operators can choose from two options when creating a review on the Access Reviews > Reviews page:
1-Step: Create a review using the quick builder by giving it a name, defining the scope, and configuring optional settings such as reviewers and due date.
Use Configuration: Open the full review builder to create a configuration, which can be used for recurring certification campaigns using the same scope. See for more information on the full query builder.
To create a review with the 1-step builder:
On the Access Reviews > Reviews page, click Create Review > 1-Step.
Enter the required details:
Review name: This will be used to identify the review in Veza and reviewer notifications. Names should be unique to simplify tracking and reporting.
Notes:
New reviews created using the 1-step builder have the "1-Step" review type.
A review configuration is created in the background, which can be used to re-initiate reviews with that scope and provide historical decision data.
1-step access reviews use to notify reviewers of assignments and deadlines, with the option to configure more granular notifications, reminders, and orchestration actions after review creation.
Reviewer Digest Notifications
Streamline reviewer communications with consolidated email summaries of pending tasks across all assigned 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.
Add questions to the set:
Set clear, concise question text
Choose the answer type (Multiple Choice or Free Form)
For multiple choice, define answer options in logical order, including an "Other" option if flexibility is needed
Click Save to create the question set
Save the configuration
After completing the questions, the decision is submitted
Unanimous Rejection: In unanimous rejection mode, responses are propagated but rows remain unsigned until all levels reject
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.
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:
Navigate to Access Reviews > Settings.
Locate the Digest Notifications section.
Enabling Digest Notifications
Toggle the Enable switch to turn Digest Notifications on or off.
Setting Normal Delivery
Under Normal delivery, select how often users should receive digests for regular notifications:
Choose the frequency:
Set the number (1-6 for days, 1-23 for hours)
Select the unit (day, hour, or week)
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
Under Snooze, select the days of the week when notifications should not be delivered.
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:
Expand the Exclude reviews section within Digest Notifications.
Select one or more labels from the dropdown.
Changes save automatically.
Reviews with any of the selected labels will be excluded from digest notifications. For alert notification exclusions, see Configure Notification Exclusions.
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.
Option
Description
All Users
All users with pending review tasks receive digest emails. This is the default behavior.
Admin Users Only
Only users with administrator roles receive digest emails. Use this option to limit notifications to administrators while non-admin reviewers rely on other notification methods.
This is a global setting that applies to all digest notifications. Individual users can still manage their personal digest preferences from their user profile settings.
Customizing digest email content
To customize the content, styling, and branding of digest notification emails, see Notification Templates in the Administration section.
Veza API key for authentication.
Generate keys in Administration > API Keys.
Body
enabledbooleanOptional
auth_provider_idstringOptional
user_typestringOptional
instance_idstringOptional
user_identity_propertystringOptional
instance_id_propertystringOptional
manager_identity_propertystringOptional
fninteger · enumOptional
The comparison function to use for this condition. For list properties (like emails), use LIST_ANY_ELEMENT_* functions. Value 5 (LIST_CONTAINS) is deprecated - use LIST_ANY_ELEMENT_EQ instead.
Example: 0Possible values:
propertystringOptional
The node property to compare. Use the property name as shown in the Graph. For custom properties from OAA integrations, prefix with customprop_ (e.g., customprop_display_name).
Example: email
valueanyOptional
Represents a dynamically typed value which can be either null, a number, a string, a boolean, a recursive struct value, or a list of values.
notbooleanOptional
If true, negates the condition (e.g., fn=EQ with not=true means "not equals").
Default: false
value_property_namestringOptional
If value_property_name is set, the value will be retrieved from the property instead of using value above
value_property_from_other_nodebooleanOptional
Only effective when value_property_name is used.
true -> value from <other_node>.<value_property_name>
false (default) -> value from <current_node>.<value_property_name>
A "true" input is valid only in destination nodes.
source_propertystringOptional
Property from saved query (RIGHT) to extract for IN_FROM_QUERY_SOURCE_RESULTS conditions.
Defaults to "id" if not set (for backward compatibility).
idp_typestringOptional
user_typestringOptional
instance_idstringOptional
user_identity_propertystringOptional
instance_id_propertystringOptional
manager_identity_propertystringOptional
Responses
200
OK
application/json
objectOptional
default
Default error response
application/json
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
codeinteger · int32Optional
The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].
messagestringOptional
A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.
Veza API key for authentication.
Generate keys in Administration > API Keys.
Responses
200
OK
application/json
enabledbooleanOptional
auth_provider_idstringOptional
user_typestringOptional
instance_idstringOptional
user_identity_propertystringOptional
instance_id_propertystringOptional
manager_identity_propertystringOptional
fninteger · enumOptional
The comparison function to use for this condition. For list properties (like emails), use LIST_ANY_ELEMENT_* functions. Value 5 (LIST_CONTAINS) is deprecated - use LIST_ANY_ELEMENT_EQ instead.
Example: 0Possible values:
propertystringOptional
The node property to compare. Use the property name as shown in the Graph. For custom properties from OAA integrations, prefix with customprop_ (e.g., customprop_display_name).
Example: email
valueanyOptional
Represents a dynamically typed value which can be either null, a number, a string, a boolean, a recursive struct value, or a list of values.
notbooleanOptional
If true, negates the condition (e.g., fn=EQ with not=true means "not equals").
Default: false
value_property_namestringOptional
If value_property_name is set, the value will be retrieved from the property instead of using value above
value_property_from_other_nodebooleanOptional
Only effective when value_property_name is used.
true -> value from <other_node>.<value_property_name>
false (default) -> value from <current_node>.<value_property_name>
A "true" input is valid only in destination nodes.
source_propertystringOptional
Property from saved query (RIGHT) to extract for IN_FROM_QUERY_SOURCE_RESULTS conditions.
Defaults to "id" if not set (for backward compatibility).
idp_typestringOptional
user_typestringOptional
instance_idstringOptional
user_identity_propertystringOptional
instance_id_propertystringOptional
manager_identity_propertystringOptional
default
Default error response
application/json
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
codeinteger · int32Optional
The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].
messagestringOptional
A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.
Automatically remove user access when a reviewer rejects and signs off a row during an access review.
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.
Example use case
Review Presentation Options
Access reviews can include effective permissions, intermediate entity details, or a summary of how access is derived including policies, roles, and groups.
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:
On-Demand Reviews
Enable Access Intelligence alert rules to create access reviews when query results change.
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.
Consider a User to Group access review targeting the Marketing Team group in Okta:
An access review is configured for all Okta Users with membership in the Marketing Team Okta Group.
The configuration has Revoke access of rejected row on sign-off enabled. This requires an Okta integration configured for provisioning.
A reviewer identifies that Jane Doe, who recently transferred to Sales, still has membership in the Marketing Team group.
The reviewer selects Jane Doe's membership row and chooses Reject.
When the reviewer signs off, auto-revocation sends an instruction to Okta and removes Jane Doe from the Marketing Team group.
Jane Doe's access is revoked immediately on sign-off, with no manual admin intervention or follow-up ticket required.
Enabling auto-revocation
Open a review configuration, go to the Veza Actions section, and check Revoke access of rejected row on sign-off.
Requirements
The Revoke access of rejected row on sign-off checkbox only appears when all of the following conditions are met:
Access Reviews Advanced is enabled for your tenant.
The review query selects a user as the source entity type. The destination or summary entity type — such as a role or group — must be supported for provisioning and deprovisioning.
Enable Usage for Provisioning is turned on for the target integration.
The integration is configured with sufficient permissions to manage relationships for the entity types in the query scope.
Enabling provisioning creates a dedicated integration datasource that grants permission to remove relationships. If provisioning is not enabled for an integration, the checkbox will not appear even if the integration is otherwise active and connected.
Supported integrations
Integration
Source
Removable entitlements
Active Directory
Active Directory User
Active Directory Group
Atlassian Cloud
Atlassian Cloud User
Atlassian Cloud Admin Group
Scope requirements
The source entity type must be a user identity. The destination must be a role, group, permission set, or license in the same application as the source.
Auto-revocation can remove access to an intermediate entity in a relationship path. For example, a review querying Active Directory User → AD Group → SQL Server Database paths can reject the User-to-Database relationship, revoking the intermediate group membership that grants it.
Cross-application scenarios are not supported. A review of Okta users to Snowflake databases will not show the auto-revocation option.
Source-only reviews (no destination entity) are not supported.
See also
Verify Remediations — after auto-revocation removes access, use Verify Remediations to automatically confirm the access is gone and mark rows as Fixed
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.
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.
Effective and system permissions
Depending on the Query Mode 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.
Reviewing effective access
Show intermediate relationship
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.
Intermediate role columns, shown instead of a summary of access
Summary entities
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:
Reviewing path summaries in the reviewer interface
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.
Examples
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)
For Google Groups, the kind of membership (such as owner or member)
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 Requires or Excludes Entity Types 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
Google Service Account
Google Service Account Role Binding
Google Group
Google Group Membership
If an expected entity type is not in the list of summary entities, ensure the query uses System mode, and that the entity type is not Excluded.
Policy inheritance and resource hierarchy
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 Intermediate Entities 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:
Create a configuration, and enable System mode
Pick the source and destination (Google User to Big Query Table)
Expand Advanced Options > Summary Entities
Pick the entity types Folder, Organization, Project, IAM Policy, Role Binding, and Group Membership
Finish customizing the configuration and save it
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.
Click the ellipses to view the entire access summary.
Attribute filters on related entity properties
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 specific group or role (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.
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).
Launch Configuration determines how reviews are created when rules trigger: as a single consolidated review or as separate individual reviews.
Creation Source: On the Access Reviews page, you can identify the source of a review by checking the Creation Source column. On-demand reviews will have the source RULE_TRIGGERED for Access Intelligence alerts or LCM_TRIGGERED for Lifecycle Management actions.
Implementing On-Demand Reviews
Prerequisites
Before configuring on-demand reviews, you will need to:
Create at least one access review configuration defining the scope of reviews.
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:
Navigate to the saved query
Select "Manage Rules" from the actions menu
Click "Add New Rule"
Configure the rule details:
Name and description
Severity level
Trigger conditions
Click Action -> Create Review to open the review creation plan.
Configure the plan and save it.
Save the rule, and click Save again to finish modifying the query.
See Saved Queries for more on working with existing queries.
To configure the Create Reviews settings:
Click Configure New On-Demand Review
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
If your query returns AWS roles, select a configuration designed for role reviews
For mixed entity types, select a configuration that can handle all types or expect fallback behavior
Configure Launch Options - Choose how reviews are created when the rule triggers:
Launch a single Access Review for the entire result set (Consolidated Mode: CONSOLIDATED) - Creates one review containing all triggered results
Launch a separate Access Review per result entity (Individual Mode: INDIVIDUAL
Set the duration for the review
Specify the reviewer assignment logic
Enable any Review Intelligence Rules
Save the plan.
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.
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
The same review configuration can be used across multiple rules
Enable third-party integrations or custom webhooks for Veza Access Reviews.
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.
Slack Integration in Access Reviews: Veza supports Slack notifications in two complementary ways:
Review Notifications (via Notification Settings): Sends lifecycle events (review started, completed, reassigned) and reminders to Slack channels. Configure this in the Notification Settings section when creating or editing a configuration.
Veza Actions: Triggers specific actions when decisions are made (rows approved/rejected). Configure this in the Veza Actions section.
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.
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:
Go to Access Reviews> Configurations to create or edit a configuration.
In the configuration editor, scroll down to Veza Actions:
Toggle events that will trigger actions.
To configure Veza Actions for a 1-step review:
Go to Access Reviews > Reviews, or open the review from the Configuration Details page.
Click on the review name to open the reviewer's interface.
On the Review Details sidebar, find the Veza Actions section and click Configure Veza Actions.
Auto-revocation
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 .
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
Field
Type
Description
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,
Tags and enrichment metadata
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:
Verify Remediations
Automatically confirm that access rejected during a review has been removed, and mark remediated rows as fixed.
Access Reviews help organizations identify and remediate inappropriate entitlements. The Verify Remediations feature helps you reconcile that rejected access has actually been revoked, by automatically confirming that access rejected during a review is no longer detected by Veza. When this reconciliation occurs, Access Reviews marks those rejected rows as Fixed in the review.
How it works
When a reviewer rejects a row in an access review, Veza runs background validation that can detect whether the access described by that rejected row still exists after Veza re-extracts user and access data for the applicable integration and datasource. If the rejected access is no longer detected, it is removed from the Access Graph, and Access Reviews will also mark the applicable row in the review as Fixed. For example, for a review of Okta Users to Okta Groups:
A reviewer rejects an Okta user's access to a particular Okta group.
The decision is signed off.
Once the review has been completed or reaches its due date, Veza will periodically query the Access Graph to check if the rejected Okta User → Okta Group access relationship still exists in your environment.
This provides an auditable record of successful remediations without requiring manual follow-up.
Note: The Verify Remediations feature is agnostic to the method of access revocation. Access can be removed automatically using Veza's capabilities, programmatically removed, or manually removed using out-of-band means. Once the rejected access is no longer detected in the Access Graph, the corresponding row in the access review is marked as Fixed.
Automated datasource extractions, CSV file uploads, and data pushes for OAA-based integrations should continue at regular intervals post-review completion to ensure Verify Remediations remains effective.
The feature is disabled by default. To use it, enable it in Access Reviews > Settings or within a review configuration.
Sign-off requirements
A sign-off must occur on the rejected row before Veza will check that row against the Access Graph. The verification only processes rows that have been both Rejected and Signed Off by a reviewer.
Sign-off can occur in two ways:
Manually: A reviewer explicitly signs off on their rejected decisions using the sign-off action in the Reviewer Interface, or uses the Reject & Sign-Off combined action.
Automatically: Rows that are auto-rejected by system events (such as review auto-expiration or auto-advance at due date) are signed off automatically.
Validation timing and duration
Depending on the configured trigger, the validation job starts either when the review reaches its due date or when all rows are completed. Processing continues until all signed-off rejected rows are validated or the configured maximum validation duration is reached (default is 30 days).
Configuring Verify Remediations
The Access Reviews section in the Veza administrative console provides a simple on/off toggle for enabling Verify Remediations, either globally or per-Review Configuration. When enabled, the following defaults are applied automatically:
Setting
Default
For full trigger options and custom durations, use the .
Global Settings
To enable Verify Remediations for all Review Configurations that do not have their own override:
Go to Access Reviews → Settings.
On the Reviews tab, scroll down to the Verify Remediations card.
Toggle Mark verified remediations as fixed on.
Review Configuration
To enable Verify Remediations for a specific review configuration:
Go to Access Reviews → Configurations.
Click the configuration name, then click Edit.
In the configuration wizard, scroll to or click Verify Remediations in the right-side step navigation.
Settings configured at the review configuration level override the global setting for that configuration.
Configure via the API
Administrators can configure all options for Verify Remediations via API, including the trigger condition, the validation duration, and the behavior when validation succeeds. Settings can apply globally or to a specific review configuration.
The toggle in the administrative interface enables Verify Remediations with fixed defaults: validation triggers on review completion and runs for up to 30 days. To use any of the following, configure the feature via API:
Trigger on due date — start validation as soon as a review reaches its due date, without waiting for completion or expiration
Custom validation windows — set a duration other than the default 30 days
Per-configuration overrides — enable globally but disable for a specific configuration, or use different settings per configuration
Required permissions
Operation
Roles
Update settings
Request body
Fields
Field
Type
Required
Description
Behavior values
Value
Description
Trigger values
Value
Description
Get current settings
Query parameters
Parameter
Type
Required
Description
Response
Example: Enable with on-due-date trigger and 14-day window
Enables Verify Remediations globally. Validation starts as soon as a review reaches its due date, and the job will continue checking for up to 14 days.
Example: Disable for a specific review configuration
Disables Verify Remediations for a single review configuration, overriding the global setting for that configuration. Replace the workflow_id value with the ID of the target configuration.
Both features use the same Slack webhook configuration but serve different purposes in your review workflow.
Complete review: When the review is marked "Complete."
: Supports
Approve Row
and
Reject Row
.
Jira: Supports Reject Row.
ServiceNow: Supports Reject Row.
Pick a Veza Action for each event.
Save the configuration.
Use the modal to assign or change the actions associated with different event types, and click Save when finished.
UUID
A unique identifier for the review.
message
String
A summary message describing the event.
requestor
String
The email address of the user who initiated the review.
email
,
guest
,
idp_type
,
idp_unique_id
,
is_active
,
manager_email
,
manager_idp_unique_id
,
manager_name
,
property_*
,
provider_id
,
provider_name
,
type
.
decision: possible values are decisions are 1: NONE, 2: ACCEPTED, 3: REJECTED, 4: FIXED.
If the access is no longer present, Veza marks the rejected row as Fixed and records a note: "Rejected access no longer detected by Veza." The action log records the change as performed by the System.
Toggle Mark verified remediations as fixed on.
Controls what happens when validation runs. See .
value.trigger
string
Yes
Determines when the validation job starts. See .
value.max_validation_duration_days
integer
Yes
How many days the job continues attempting to validate before giving up. Must be greater than 0. Once all signed-off rejected rows are validated, the job stops immediately regardless of this value.
If provided, applies settings only to this review configuration. If omitted, applies globally to all configurations that do not have their own settings.
The validation job starts when a review enters the Completed or Expired state. Note: a review that is past its due date is not the same as an expired review. For a review to expire, it must have a due date and review expirations must be enabled.
ACCESS_REMEDIATION_VALIDATION_TRIGGER_ON_DUE_DATE
The validation job starts as soon as the review reaches its due date, regardless of whether review expiration is enabled. If the review has no due date, this behaves identically to ON_COMPLETION and the job will not start until the review is completed.
GET /api/private/workflows/access/global_settings/remediation_validation_behavior
workflow_id
string
No
If provided, returns the settings for this review configuration. If omitted, returns the global settings.
Customizing Access review behavior for specific business needs and use cases.
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:
Some of these options must be enabled by the Veza support team, while others can be configured using an API. See Access Review Settings 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 Veza local users. 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.
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 Sign-in Settings: Default Roles.
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).
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.
Auto-assignment takes place during review creation. To inform reviewers who are auto-assigned when creating the review, ensure that notification emails trigger "When a review is started" in the review Notification Settings.
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: "[email protected]" cannot be assigned as a reviewer for any row in a review involving Okta User "[email protected]."
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 [email protected] won't be allowed to be a reviewer for any rows that involve his local Snowflake User account jsmith.
Self-review prevention, as well as the , applies when auto-assigning reviewers during review creation.
Self-review prevention can be enabled or disabled via API. Possible settings are:
SELF_REVIEWER_CHECKING_DISABLED (default)
SELF_REVIEWER_CHECKING_ENABLED
Self-review prevention can be configured globally (applying to all reviews) or per review configuration (overriding the global default for a specific configuration). When a configuration-specific setting is present, it takes precedence over the global setting. Use the workflow_id parameter in the Self Review Prevention API to target a specific review configuration.
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:
The blocked user’s manager or resource owner (if not explicitly inactive)
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.
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 autocompletion occurs only when all rows were signed off as approved or were rejected but marked as “fixed.”
When an option other than COMPLETION_ALLOWED_ANYTIME is selected, reviewers will not have the option to manually Complete Review from the user interface, and empty reviews (ones created with no results) will always autocomplete.
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 API.
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:
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.
To set defaults directly from the reviewer interface, arrange columns and click Admin > Set Columns as Default. This saves the column layout and any active row grouping as the default for that configuration. For global defaults or automation, use the API.
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.
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 API.
Example sort setting:
Reviewer interface preferences are saved to the browser. If a user has already customized columns, changes to the default settings won't apply.
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): Focus on rows needing attention first
By risk level (risk_level): Prioritize high-risk access
Early Access Feature: Outlier Detection is currently in Early Access and available via API only. Contact your Veza Customer Success Manager to enable this feature for your tenant.
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
Flexible grouping: Customize peer grouping by department, location, role, or other properties
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
By role: Flag access rare among users with the same job role
By resource classification: Flag access rare for resources with the same classification level
Emails sent by Veza can include instructions, unique branding, and placeholders for metadata specific to the review. See Notification Templates API 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.
Templates can include links to images hosted externally or you can upload small files to Veza.
In addition to emails, administrators can add customized instructions that will be shown in a splash page when opening the reviewer interface. See for more information.
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
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.
For self-service row highlighting with custom colors, see Review Intelligence Policies. Automations with the HIGHLIGHT display style support any hex color and do not require contacting support.
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 API. 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:
Export permissions apply to all reviewers assigned to a review. Administrators and operators retain the ability to export data regardless of this setting. Export format controls are independent. You can enable CSV exports while disabling PDF and XLSX exports based on your security requirements.
When configured for a specific review configuration (using workflow_id), those settings override any global export permissions for reviews created from that configuration.
Reviewer bulk actions
Administrators can control which bulk actions are available to reviewers. Six granular toggles allow enabling or disabling specific bulk operations: approve, reject, sign off, clear decisions, add note, and reassign. This is useful for enforcing specific review workflows or preventing reviewers from performing certain actions in bulk.
Bulk action restrictions apply only to users with the reviewer role. Administrators and operators retain full access to all bulk actions regardless of these settings. Single-row operations (acting on one row at a time) are never restricted.
These settings are managed from App Settings > Reviews tab > Reviewer Bulk Actions, where each action has its own checkbox. You can also configure them programmatically using the Reviewer Bulk Actions Settings API. Settings can be applied globally for all reviews or overridden for specific review configurations. All bulk actions are enabled by default.
What counts as "bulk": Bulk actions include any operation applied to two or more rows, including multi-row checkbox selection, "Select All", and filter-based operations. When a bulk action is disabled, any Smart Actions that use the disabled action type are also hidden from reviewers.
Example request to disable bulk approve and reject globally:
Example request to disable all bulk actions for a specific review configuration:
Enable reviewer reassignment
Controls whether users acting as assigned reviewers can reassign rows to other reviewers. When enabled (the default), any user assigned as a reviewer on specific rows can reassign those rows. When disabled, assigned reviewers cannot reassign rows.
Note that Administrators, Operators, and Reassigners always retain reassignment privileges, regardless of this setting. This setting only affects users acting in the capacity of an assigned reviewer.
This setting can be configured globally or overridden for a specific review configuration.
These settings are managed from Access Reviews > Settings > Enable Reviewer Reassignment. You can also configure them using the Reviewer Reassignment Settings API.
Value
Description
ALLOWED
Assigned reviewers can reassign rows (default)
NOT_ALLOWED
Assigned reviewers cannot reassign rows
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
Example request to require due dates for first-level reviews:
Example request to configure a specific review configuration:
When mandatory due dates are enabled, the review creation interface will prevent submission until a valid due date is specified. Existing reviews are not affected by changes to this setting.
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 Quick Filters for more information about adding pre-built filters.
Action Allow List
Restrict which users can delete in-progress reviews or modify their due dates, independent of their Veza role. When enabled, only users added to the allow list can perform these actions. Users not on the list will not see the Delete or Edit Due Date controls in the review management interface.
Draft reviews are not affected. The allow list is configured using the API.
Customizing notifications and reminders for Veza Access Reviews via email and Slack.
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.
Delivery Methods
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.
The feature flag UI_SLACK_APP_INTEGRATION must be enabled for your organization (contact Veza support)
Users must exist in both Veza and Slack with matching email addresses
Configuring Delivery Methods
When creating or editing an Access Review configuration:
Navigate to the Notification Settings section
Under Delivery options, select:
Email: Send notifications via email
Slack App: Send direct messages to reviewers via Slackbot
If Slack App is enabled, choose your configured Slack App from the dropdown
Select which events trigger notifications:
Review started
Review completed
Reviewer changed
All configured notification events will be delivered as direct messages to assigned reviewers through the selected delivery methods.
For team channel notifications: Use Slack webhooks in the Veza Actions section to post decision events (approve/reject/complete) to team channels. See Slack Webhook Integration. Both direct messages and channel notifications can be used simultaneously.
First-Time User Experience
When reviewers receive their first Slack notification:
If they haven't connected their Slack account to Veza, the message includes a "Connect" button
Clicking "Connect" redirects them to Veza's login page
After authentication, their Slack and Veza accounts are linked
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.
Administrators can configure global notification exclusions to prevent specific reviews from sending digest notifications or alerts based on labels. See Configure Notification Exclusions.
Configuring notifications & reminders
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.
(Number of days) after due date: Sent when the review deadline has passed.
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.
Reminders and final reminders are sent at 11 AM PST on the specified date.
Reassignment Needed notifications
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.
Prerequisite: Reassignment Needed notifications require a Global Identity Provider to be configured. When a global IdP is configured, the Reassignment Needed section appears in the review configuration's notification settings.
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.
Unlike other notification types, Reviewers is not a recipient option for Reassignment Needed notifications. Only Reviewer Managers and Additional Recipients are available, so that notifications reach someone with authority to reassign the affected rows.
To enable Reassignment Needed notifications:
Go to Access Reviews > Configurations and open a configuration.
Click Edit and scroll to the Advanced Notifications section.
Under Reassignment Needed, check Reviewer account has been detected as inactive.
Select recipients:
Reviewer Managers: Notifies the manager of each inactive reviewer. Veza sends a separate email to each manager listing only their direct report's affected rows.
Additional Recipients: Sends a single email listing all inactive reviewers across the review.
Save your changes.
Edit notifications and reminders for a configuration
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:
Go to Access Reviews > Configurations.
Click the configuration name to view details.
On the Configuration Details page, click Edit.
Scroll down to the Advanced Notifications section.
Configure notification settings using the checkboxes to enable recipients and triggers:
Review Notifications:
Under When, select events that trigger notifications (Review has been started, Review has been completed, Review row has been reassigned)
Save your changes.
Edit notifications and reminders for a review
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:
Go to Access Reviews > Reviews, or open the review from the Configuration Details page.
Click on the review's name to open the reviewer's interface.
On the Review Details sidebar, find Notifications and Reminders and click Open.
Open notification settings or edit Veza Actions.
Use the Edit Configuration Notifications & Reminders form to add recipients and triggers.
Click Save when finished.
Customizing notification content
To customize the email content, subject lines, and branding for Access Review notifications, see Notification Templates in the Administration section.
Delivery Settings - Configure digest schedules and recipient controls
Reminder notifications
Escalation notifications
Under Notify, select recipients (Reviewers, Managers, Additional Recipients)
Reviewer Notifications:
Under When, select timing conditions (Review is due, days before a review is due, days after a review is due, or reminders when no changes have been made)
Under Notify, select recipients (Reviewers, Managers, Additional Recipients)
Configure the Slack App Veza Action for direct message delivery to Access Review reviewers.
Veza's Slack App integration sends direct message notifications to users for Access Reviews and Access Requests. Unlike webhook integration, which posts messages to Slack channels, this integration delivers notifications directly to users via the Veza Slackbot, using Block Kit for rich notification formatting and enabling interactive approval workflows.
By completing this guide, you will:
Create a Veza OAuth2 client for user authentication
Create and configure a Veza Slack app in your Slack workspace
Configure the Slack App Veza Action in Veza
Enable direct message delivery for Access Reviews and Access Requests
Optionally enable alert and digest notification delivery
Comparison with Slack Webhook Integration
This integration complements channel-based Slack integration. Both can be used together for channel announcements and direct messages to reviewers:
Prerequisites
Admin access to your Slack workspace
Users must exist in both Veza and Slack with matching email addresses
Each reviewer must connect their Slack account to their Veza account on first use (see )
Before enabling for production: Test the integration with yourself as a reviewer first. The Veza Slackbot sends direct messages to all assigned reviewers in your organization. Inform users they might receive messages from the bot. Consider keeping email notifications enabled as a backup during initial rollout.
Network requirements
The integration requires inbound connectivity to your Veza tenant from Slack's servers and user browsers:
Endpoint
Accessible From
Purpose
How user matching works
User email addresses in Slack must exactly match the reviewer's email address in Veza. The Veza Slackbot matches users using the following process:
Veza identifies the reviewer: The user is assigned to a review in Veza Access Reviews
Email lookup: Veza takes the user's email address from their Veza account
Slack user search: The integration calls Slack's users:lookupByEmail API to find a matching user
First-time user connection
When a Slack user receives their first notification from Veza, they must connect their Slack account to their Veza account:
The notification includes a Connect button instead of action buttons
Clicking Connect redirects the user to Veza's standard login page
The user logs in with their existing Veza credentials (local account or SSO)
The connection flow uses PKCE (Proof Key for Code Exchange) for security. Connection requests expire after 10 minutes.
Global IdP not required: The Slack integration uses the email address from the Veza user account, regardless of whether you have a configured. If you use a Global IdP, ensure the email addresses match those in Slack.
Setup Process
Step 1: Create Veza OAuth2 Client
Before creating the Slack app, you must create an OAuth2 client in Veza. This enables the user authentication flow when Slack users click interactive buttons (Connect, Approve, Deny).
Navigate to Administration > Sign-in Settings
Enable Veza OAuth2 Authorization Server
Navigate to Administration > API Keys > OAuth2 Clients
Veza returns credentials required for the Slack app configuration:
Save these values: You will use them as Veza OAuth Client ID and Veza OAuth Client Secret when configuring the Slack app in Veza.
Step 2: Create the Veza Slack App
Using the app manifest (recommended)
Go to and click Create New App
Select From an app manifest
Choose your workspace
Paste the manifest below, replacing
Gather required credentials
After installation, collect these values from your Slack app:
Credential
Location
Format
You will also need the Veza OAuth Client ID and Veza OAuth Client Secret from . These are required to enable interactive Approve/Deny buttons for Access Requests.
Step 3: Configure in Veza
Navigate to Integrations > Veza Actions
Click Add Veza Action and select Slack App
Provide the required information:
Test connection validation
The test performs these checks:
Bot Token authentication: Verifies the bot token is valid and can connect to Slack
Workspace access: Confirms the bot has access to the configured workspace
Using the Slack App Veza Action
Enable Slack delivery on a configuration
To enable Slack notifications for an individual Access Review configuration:
Navigate to Access Reviews > Configurations
Create or edit a configuration
In the Notifications step, under Delivery options, enable the Slack checkbox
Enable Slack delivery for alerts
Alerts send immediate notifications when reviewers are assigned to new reviews. To enable Slack delivery for alerts:
Navigate to Access Reviews > Settings > Notifications
Under Alerts, enable the toggle
Under Delivery options, enable the Slack checkbox
For more information on alert configuration, see .
Enable Slack delivery for digest notifications
Digest notifications send periodic summaries of pending reviews. To enable Slack delivery for digests:
Navigate to Access Reviews > Settings > Notifications
Under Digest Notifications, enable the toggle
Under Delivery options, enable the Slack checkbox
For more information on digest configuration, see .
You can enable Email, Slack, and Microsoft Teams simultaneously. Reviewers receive notifications through all enabled channels.
Using Slack App in Access Requests
Access Request approvers can approve or deny access requests directly from Slack without needing to log in to Veza.
Configure notification settings for approvers
To send Access Request notifications via Slack:
Navigate to Lifecycle Management > Settings > Access Request Settings
Scroll to the Notifications section
Click Add Notification or edit an existing notification
Unlike Access Reviews (configured per-review), Access Request Slack notifications are configured globally in Lifecycle Management Settings and apply to all access requests.
What approvers see
When an access request requires approval, the approver receives a Slack direct message:
Button actions:
Connect (first-time only): Authenticates the Slack user with their Veza account via the OAuth flow configured in Step 1
Approve: Approves the access request directly from Slack
Deny: Rejects the access request directly from Slack
After clicking Approve or Deny, Slack displays a confirmation message indicating the action was successful.
Self-approval blocked: Approvers cannot approve their own access requests. If an approver attempts to approve their own request, the action will fail.
Customize notification templates
The Slack App Veza Action uses JSON templates. Veza provides default templates for each notification event type, including review notifications, alerts, and digests. You can create custom templates to modify the content and layout.
To create a custom template:
Navigate to Access Reviews > Settings > Notifications
Click Create Template
Select the notification event type (review events, Alerts, or Digest)
You can create one custom template per event type. Alert and digest templates each support a single custom template that applies across all configurations.
For more information on template customization, see .
Default templates
Veza includes default Block Kit templates for each notification event type.
Review notifications:
Event
Default message
Alerts and digests:
Event
Default message
Each default template includes an action button linking to the review or reviews list.
Common template placeholders
Slack templates support placeholder tokens that are replaced with dynamic values at send time. Common placeholders include:
Placeholder
Description
The same placeholders are available for Email, Slack, and Teams templates. For the complete list of all available placeholders organized by notification event type, see .
What users see
Reviewers receive direct messages containing Block Kit messages with review information and action buttons.
First notification (before connecting):
Veza needs to verify your identity.
[Connect]
After clicking Connect and logging in to Veza, the user's Slack account is linked to their Veza account.
Review started notification:
The review Quarterly Access Review was started.
[View in Veza]
Inactivity reminder:
Quarterly Access Review review has had no activity from Alex Wilber for 3 days.
Alex Wilber has 15 of 42 rows that need to be signed off.
[View in Veza]
Due date reminder:
Quarterly Access Review review is due in 2 days.
[View in Veza]
Digest notifications
When digest notifications are enabled, reviewers receive consolidated Block Kit summaries listing all pending reviews, items remaining, and due dates, with a Go to My Reviews action button.
Limitations
Before enabling the Slack App integration, note the following limitations:
Email matching required: Users must have matching email addresses in both Veza and Slack. The match is case-sensitive.
User connection required: Each reviewer must connect their Slack account to their Veza account by clicking Connect on their first notification and logging in. Until connected, users cannot take actions (Approve/Deny) from Slack.
No delivery failure alerts: Veza does not currently track or raise alerts when a Slack message fails to deliver. If a notification cannot be sent (for example, because the user's email doesn't match or the bot cannot reach the user), the failure is logged internally but no alert is surfaced to administrators. Consider keeping email notifications enabled as a fallback.
PLAT_OAUTH2_TOKEN_PROVIDER — Required for user authentication flow
User's browser
OAuth callback after Veza login
Direct message delivery: If found, the notification is sent as a DM to that Slack user
After successful authentication, Veza securely stores the binding between the Slack user ID and the Veza user account
All subsequent notifications include interactive buttons without requiring reconnection. Access Request notifications include Approve and Deny buttons; Access Review notifications include a View in Veza button
Click Add New OAuth2 Client
{customer_cluster_url}
with your Veza instance URL (e.g.,
https://yourcompany.veza.cloud
):
Review and click Create
Navigate to Install to Workspace and authorize the app
Basic Information > App Credentials
Hex string
Bot Token
OAuth & Permissions > Bot User OAuth Token
Starts with xoxb-
Name: Descriptive name (e.g., "Slack Direct Messages")
Client ID: From Slack app credentials
Client Secret: From Slack app credentials
Signing Secret: From Slack app credentials (verifies webhook authenticity)
Token: Bot User OAuth Token (xoxb-...)
Veza OAuth Client ID: From Step 1 (OAuth2 client creation)
Veza OAuth Client Secret: From Step 1 (OAuth2 client creation)
Click Next and Test Connection
Veza verifies the Bot Token can connect to your Slack workspace
Click Create to save
If you have multiple Slack App Veza Actions configured, select the desired one from the dropdown
If you have multiple Slack App Veza Actions configured, select the desired one from the dropdown
If you have multiple Slack App Veza Actions configured, select the desired one from the dropdown
Configure the notification:
Event Type: Select which event triggers the notification (e.g., Request Submitted, Request Approved)
Notification Type: Select Slack App
Slack App: Choose your configured Slack app from the dropdown
Send To: Check Approvers to send notifications to access request approvers
Click Save
View in Veza: Opens the full request details in your browser
Under Deliver via, select Slack
Edit the Block Kit JSON body
Save the template
"The owner of review configuration {name} has changed from X to Y."
Reminder: No activity
"{name} review has had no activity from {reviewer} for X days."
Reminder: Due date
"{name} review is due in X days."
Row approved
"In the access review {name}, access for X rows was approved."
Row rejected
"In the access review {name}, access for X rows was rejected."
List of reviewer emails
{{WORKFLOW_CERT_DUE_ON_DATE}}
Review due date
{{WORKFLOW_CERT_DUE_ON_PHRASE}}
Human-readable due date (e.g., "is due in 3 days")
