# Access Reviews Settings 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: * [Access Reviews Global Settings](#access-reviews-global-settings) * [Suggest reviewers from a global identity provider](#suggest-reviewers-from-a-global-identity-provider) * [Reviewer auto-assignment](#reviewer-auto-assignment) * [Self-review prevention](#self-review-prevention) * [Self-review prevention with auto-assignment](#self-review-prevention-with-auto-assignment) * [Review completion settings](#review-completion-settings) * [Autocompletion](#autocompletion) * [Enable or disable review expiration](#enable-or-disable-review-expiration) * [Requiring notes with decisions](#requiring-notes-with-decisions) * [Change default columns and sorting](#change-default-columns-and-sorting) * [Review row grouping](#review-row-grouping) * [Outlier detection](#outlier-detection) * [Customize reminder and notification emails](#customize-reminder-and-notification-emails) * [Notification exclusions](#notification-exclusions) * [Review interface presentation rules](#review-interface-presentation-rules) * [Reviewer export permissions](#reviewer-export-permissions) * [Reviewer bulk actions](#reviewer-bulk-actions) * [Enable reviewer reassignment](#enable-reviewer-reassignment) * [Mandatory due dates](#mandatory-due-dates) * [Saved filters](#saved-filters) * [Action Allow List](#action-allow-list) Some of these options must be enabled by the Veza support team, while others can be configured using an API. See [access-review-settings](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings "mention") 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/administration/administration/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. * To enable a global Access Reviews Identity Provider, see [global-idp-settings](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings "mention"). Enabling a global identity provider also enables reviewer auto assignment to [managers-and-resource-owners](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/managers-and-resource-owners "mention"). * 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/administration/administration/sign-in-settings/sso-feature-role-mapping#default-team-and-role-assignments). ### Reviewer auto-assignment You can choose to auto-assign managers and resource owners when creating a review or re-assigning reviewers. Any rows in the review that cannot be auto-assigned are assigned to fallback reviewer(s). To enable Veza to automatically identify managers and resource owners, see [managers-and-resource-owners](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/managers-and-resource-owners "mention"): * 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. {% hint style="info" %} 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*. {% endhint %} ### Self-review prevention You may want to prevent reviewers from being able to review and sign off on their own access in a review. When self-reivew prevention is enabled and a Global IdP is configured, users cannot be assigned to review rows for identities that match their global unique ID: * Users with an ID that correlates to a review row cannot be assigned as reviewers for that row: "" cannot be assigned as a reviewer for any row in a review involving Okta User "." * Users cannot be assigned to review access for *local user accounts* for which they're the top-level identity (if Veza has detected a correlation between an IdP User with id `john@cookie.net` and the local Snowflake User `jsmith`, IdP User won't be allowed to be a reviewer for any rows that involve his local Snowflake User account `jsmith`. * Self-review prevention, as well as the [deny list](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/updatereviewerdenylist), applies when auto-assigning reviewers during review creation. Self-review prevention can be enabled or disabled via [API](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/selfreviewprevention). 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/selfreviewprevention) 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: 1. The blocked user’s *manager or resource owner (if not explicitly inactive)* 2. The *configuration creator* 3. A *Veza system administrator*. See [reviewer-selection-methods](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/reviewer-selection-methods "mention") to customize this behavior. ### Review completion settings Depending on how your organization conducts access reviews, you may prefer that users be able to complete reviews at any point, or want reviews to autocomplete when certain requirements are met. #### Autocompletion By default, a review must be manually marked "complete" once a reviewer has signed off on all decisions. This setting can be changed so that reviews move are considered complete once a reviewer signs off on the final row. You can also customize autocomplete behavior to allow or prevent autocompletion of reviews that contain "Rejected" decisions. This behavior is customizable using an [API](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/reviewautocompletesettings). Example request: ```json {"value":"COMPLETION_ALLOWED_ALL_ROWS_HAVE_NON_REJECT_DECISION"} ``` Possible values are * `COMPLETION_ALLOWED_ALL_ROWS_HAVE_DECISION` (default): Once all rows have a decision, the review will be automatically marked as complete and no further changes can be made. * `COMPLETION_ALLOWED_ANYTIME` Any reviewer can click *Complete* to finish and close the review at any point. * `COMPLETION_ALLOWED_ALL_ROWS_HAVE_NON_REJECT_DECISION` autocompletion occurs only when all rows were signed off as approved **or** were rejected but marked as “fixed.” {% hint style="info" %} 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. {% endhint %} 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: ```json {"value":"AUTO_COMPLETE_ENABLED"}'} ``` #### 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/expireoverduereviews). #### Requiring notes with decisions By default, adding a note is optional when making decisions on rows. However, you may prefer that reviewers be required to leave a note under certain conditions. For example, you could require a note for rejected rows, while prompting (but not requiring) a note for approved rows. *Notes pop-up behavior* sets whether the "Notes" modal appears and if a note is required when making decisions on rows. "Approve" and "Reject" behavior can be customized separately: * Approved notes behavior: * No pop-up * Optional (default) * Required * Rejected notes behavior: * No pop-up * Optional (default) * Required This behavior is customizable using an [API](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/reviewuicustomizations). Example request: ```json { "value": { "accept_notes_behavior": "POP_UP_OPTIONAL", "reject_notes_behavior": "POP_UP_REQUIRED" } } ``` 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. See [columns](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/columns "mention") for column syntax reference, UI walkthrough, and API documentation. The following example sets global default columns based on the source, destination node, and intermediate (waypoint) node properties, and shows each row's reviewers. It also hides sensitive columns from reviewers while keeping them visible to administrators: ```json { "value": { "default_ordered_columns": [ "source.customprop_worker_status", "source.name", "concrete_perms", "destination.name", "reviewers", "destination.customprop_asset_id", "destination.customprop_bu", "destination.customprop_display_name", "waypoint.name" ], "hide_from_reviewers_columns": [ "source.identity_unique_id", "idp.on_premises_distinguished_name" ] } } ``` The default sort value is `source.type asc`, and can be configured using an [API](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/reviewsortorder). Example sort setting: ```json {"value":{"order_by":"source.name desc"}}' ``` {% hint style="info" %} Reviewer interface preferences are saved to the browser. If a user has already customized columns, changes to the default settings won't apply. {% endhint %} ### 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 For detailed API documentation and examples, see [Review Row Grouping Settings](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/reviewrowgrouping). ### Outlier detection {% hint style="warning" %} **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. {% endhint %} 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 For detailed API documentation, configuration examples, and use cases, see [Outlier Detection Settings](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/outlierdetection). ### Customize reminder and notification emails Emails sent by Veza can include instructions, unique branding, and placeholders for metadata specific to the review. See [notification-templates](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/notification-templates "mention") 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 [help-page-templates](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/help-page-templates "mention") for more information. See [email-templates-api](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/notification-templates/email-templates-api "mention") for preview API usage details. ### Notification exclusions Administrators can configure label-based exclusions to prevent specific Access Reviews from generating notifications. Exclusions can be configured independently for: * **Digest Notifications**: Exclude reviews from periodic digest emails * **Alerts**: Exclude reviews from immediate notifications when reviewers are assigned For configuration instructions, see [Configure Notification Exclusions](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/configure-notification-exclusions). ### Review interface presentation rules To enable easier identification of potentially dangerous results, Veza supports custom styling rules to highlight disabled (inactive) users. In addition to these rows appearing in red during review, the text summary shown when hovering the row will indicate that the user is inactive. Please contact your Veza customer success team to enable this option. To highlight results based on a custom presentation rule, provide: * The filter string to use (for example `source.is_active eq false`). The property to match can be on the source or destination entity types in the configured query. * (Optional) a list of `review id`s 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/review-intelligence-rules). 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/reviewerexportsettings). The setting can be configured globally for all reviews or for specific review configurations. Example request to disable all exports (default): ```json { "value": { "allow_csv_exports": false, "allow_pdf_exports": false, "allow_xlsx_exports": false } } ``` Example request to enable only CSV exports for a specific review configuration: ```json { "value": { "allow_csv_exports": true, "allow_pdf_exports": false, "allow_xlsx_exports": false }, "workflow_id": "8ae1c414-3a76-46cb-950a-925316b3f264" } ``` {% hint style="info" %} 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. {% endhint %} ### 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. {% hint style="info" %} 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. {% endhint %} 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/reviewerbulkactionssettings). Settings can be applied globally for all reviews or overridden for specific review configurations. All bulk actions are enabled by default. {% hint style="warning" %} **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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/smart-action-definitions) that use the disabled action type are also hidden from reviewers. {% endhint %} Example request to disable bulk approve and reject globally: ```json { "value": { "allow_bulk_approve": false, "allow_bulk_reject": false, "allow_bulk_signoff": true, "allow_bulk_clear_decisions": true, "allow_bulk_add_note": true, "allow_bulk_reassign": true } } ``` Example request to disable all bulk actions for a specific review configuration: ```json { "value": { "allow_bulk_approve": false, "allow_bulk_reject": false, "allow_bulk_signoff": false, "allow_bulk_clear_decisions": false, "allow_bulk_add_note": false, "allow_bulk_reassign": false }, "workflow_id": "8ae1c414-3a76-46cb-950a-925316b3f264" } ``` ### 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/assign-reviewers) 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](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/reviewerreassignmentsetting). | 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 This behavior is customizable using an [API](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/mandatoryduedate). Example request to require due dates for first-level reviews: ```json { "value": { "mandatory_for_first_level": true, "mandatory_for_second_level": false, "mandatory_for_third_level": false } } ``` Example request to configure a specific review configuration: ```json { "workflow_id": "8ae1c414-3a76-46cb-950a-925316b3f264", "value": { "mandatory_for_first_level": true, "mandatory_for_second_level": true, "mandatory_for_third_level": false } } ``` {% hint style="info" %} 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. {% endhint %} ### 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 [quickfilters](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/quickfilters "mention") 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. See [action-allow-list](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/action-allow-list "mention") for full configuration instructions and [actionallowlist](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/actionallowlist "mention") for the API reference.