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.

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.

Example request

Column customizations require a private API call. 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:

{
  "value": {
    "default_ordered_columns": [
      "source.name",
      "source.department",
      "source.customprop_worker_status",
      "source.tags",
      "path_summary.name",
      "concrete_permissions",
      "destination.name",
      "destination.customprop_display_name",
      "reviewers"
    ]
  },
  "workflow_id": "002063d2-7898-4183-b5fb-1192758fdec7"
}

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:

{
  "value": {
    "default_ordered_columns": [...],
    "order_by": "source.name desc"
  }
}

Column syntax

Columns for entity attributes have the format:

• source.attribute_name: Source entity attributes.

• destination.attribute_name: Destination entity attributes.

• waypoint.attribute_name: Attributes on the Relationship entity, if specified in the configuration.

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

Columns can also show row metadata:

• status

• abstract_permissions

• concrete_permissions

• updated_at

• notes

• reviewers

• decision

• decision_by

• decision_by_id

• decision_by_name

• decision_by_email

• decision_at

• marked_fixed_by_id

• marked_fixed_by_name

• marked_fixed_by_email

• marked_fixed_at

• signed_off_state

• signed_off_by_id

• signed_off_by_name

• signed_off_by_email

• signed_off_at

• notification_status

• automation_run_ids

• no_decision_or_decision_by

• is_signed_off

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.

• Managers and Resource Owners can be auto-assigned as reviewers.

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

Typically, Veza support will make the API calls required to customize global IdP settings. See the following sections for prerequisites and the request format.

Before you start

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

  • Okta

  • Microsoft Azure

  • Custom Identity Provider

• Use Query Builder to search for a user from your identity provider, and retrieve the provider’s datasource_id.

• Single Sign-On should be enabled to allow external users to log in to Veza.

• Veza support will supply an auth_provider_id for the Veza SSO connection.

Update global identity provider settings request

PUT workflows/access/global_settings/idp_settings

Enable Veza to suggest reviewers from the graph, by specifying the SSO auth provider id and the identity provider data source instance id:

    "value": {
        "enabled": true,
        "idp": {
            "auth_provider_id": "cf9bab40-4e48-4afc-a310-acfdad416233",
            "user_type": "OktaUser",
            "instance_id": "dev-5150036.okta.com",
            "user_identity_property": "idp_unique_id",
            "instance_id_property": "datasource_id",
            "manager_identity_property": "manager_idp_unique_id"
        }
    }

Notes:

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

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

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

• Veza will populate the user list by searching for nodes of type user_type with instance_id_property equal to instance_id.

• Setting "instance_id_property": "datasource_id" will typically achieve the correct behavior.

Examples

Okta:

{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "x",
      "user_type": "OktaUser",
      "instance_id": "dev-5150036.okta.com",
      "user_identity_property": "idp_unique_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_idp_unique_id"
    }
  }
}

Microsoft Azure AD:

{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "x",
      "user_type": "AzureADUser",
      "instance_id": "d5d23474-d857-4e12-bf68-75d638867e93",
      "user_identity_property": "idp_unique_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_idp_unique_id"
    }
  }
}

Custom Identity Provider:

{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "cf9bab40-4e48-4afc-a310-acfdad416233",
      "user_type": "CustomIDPUser",
      "instance_id": "aa650cf7-2370-406e-bb35-1a8e14b92919",
      "user_identity_property": "idp_unique_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_idp_unique_id"
    }
  }
}

Validating global identity provider settings

You can confirm changes are working as intended by starting 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.

Overview

Email notifications inform reviewers and other stakeholders of important events, such as when a review starts, re-assignments occur, and deadlines pass. Veza includes three types of email 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.

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.

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.

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:

1. Go to Access Reviews > Configurations.

2. Click the configuration name to view details.

3. On the Configuration Details page, click Edit.

4. Scroll down to the Advanced Notifications section.

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

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

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

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

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

3. On the Review Details sidebar, find Notifications and Reminders and click Open.
4. Use the Edit Configuration Notifications & Reminders form to add recipients and triggers.

5. Click Save when finished.

See also

• Create a Configuration

• Veza Actions for Access Reviews

• Notification Templates

• Notification Templates API

• Managers and Resource Owners

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

Suggest reviewers from a global identity provider

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.

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.

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:

• SELF_REVIEWER_CHECKING_DISABLED (default)

• SELF_REVIEWER_CHECKING_ENABLED

Self-review prevention with auto-assignment

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

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

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

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

2. The configuration creator

3. A Veza system administrator.

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.

Example request:

Possible values are

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

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

• COMPLETION_ALLOWED_ALL_ROWS_HAVE_NON_REJECT_DECISION autocompletion occurs only when all rows were signed off as approved or were rejected but marked as “fixed.”

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

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 (default)

  • Optional

  • Required

• Rejected notes behavior:

  • No pop-up (default)

  • Optional

  • Required

Example request:

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

Change default columns and sorting

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

The following example sets global default columns based on the source, destination node, and intermediate (waypoint) node properties, and shows each row's reviewers:

Example sort setting:

Customize reminder and notification emails

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

Review interface presentation rules

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

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

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

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

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.

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

Overview

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

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

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

Enabling IDP/HRIS Metadata Enrichment

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

1. Create or edit a configuration.

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

3. Select from the list of supported entity types to enable result enrichment (such as "Workday Worker" for "Okta User"):
4. Save the configuration and create a review.

5. 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 Customizing Default Columns.

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:

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

In this filtered view:

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

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

• The access relationship between Alice and Group2 remains visible.

Overview

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

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

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

• For natively-supported identity providers, such as Okta, you can assign a manager by setting a user's Manager attribute from the provider's admin console.

• Any entity in the Veza graph can have a resource owner. Apply a tag with key SYSTEM_resource_managers. The tag's value is the comma-delineated list of user ID's, for example:

  Copy

  {
  "tag": {
      "key": "SYSTEM_resource_managers",
      "value": "01a09253,928a24e4"
    }
  }

Assigning resource owners (Graph Search)

From the Veza UI, you can add a manager tag to any entity in Graph Search:

1. In Veza, go to Access Visibility > Graph.

2. Search for the entity.

3. Click the entity in the search results to open the sidebar.

4. Click Set Resource Owner.

5. In the Add Resource Owner box, type to search for users by email and Save the changes.

Assigning resource owners (Tags API)

Add tag:

curl -X POST $BASEURL/api/v1/graph/nodes/tags \
-H 'authorization: Bearer '$TOKEN \
--data-raw '{
  "node_id": "527398259632-c98becd0",
  "tags": [
    {
      "key": "SYSTEM_resource_managers",
      "value": "jim@cookie.ai"
    }
  ]
}'

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

curl -X POST $BASEURL/api/v1/graph/nodes/tags:remove \
-H 'authorization: Bearer '$TOKEN \
--data-raw '{
  "node_id": "dn44266.us-east-2.aws.snowflakecomputing.com/database/LOCATION/schema/COUNTRIES/table/USA",
  "tag_key": "SYSTEM_resource_managers"
}'

Validating manager assignments

To test resource owner assignment using tags:

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

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

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

4. Save the configuration and create a review.

5. The resource owner's Veza account should be selected as the default reviewer.

To test manager assignments using Okta:

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

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

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

4. Create a configuration. Select the entity type (OktaUser) and choose to Select a single entity. Enter the Okta user name.

5. Save the configuration and start a review.

6. The manager's Veza account will be a suggested default reviewer.

Assigning owners for custom applications and identity providers

Assigning managers (Custom IdP)

...
{
  "name": "Direct Report",
  "identity": "000001",
  "manager_id": "000011"
}
{
  "name": "Manager One",
  "identity": "00011",
  "manager_id": "00029"
}
{
  "name": "Senior Manager",
  "identity": "00029",
  "manager_id": null
}
...

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:

{
  "name": "Custom User",
  "identity": "000011",
  "entities_owned": [
    {
      "node_type": "S3Bucket",
      "id": "arn:aws:s3:::amazon-connect-53f87966654d"
    }
  ]
}

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.

Assigning resource owners (Custom Application)

When using the custom application template to submit application and resource metadata, assign resource owners by applying a Veza tag:

          "name": "release.vezacloud.com",
          "resource_type": "Cluster",
          "description": "release staging cluster",
          "sub_resources": [],
          "tags": [
            {
              "key": "system_resource_managers",
              "value": "ops@veza.com"
            }

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.

To create a review with the 1-step builder:

1. On the Access Reviews > Reviews page, click Create Review > 1-Step.
2. 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.

   • Scope: Choose an option to define the entities and relationships to review:

     • Quick Builder:

       • Review Type: The type of entities and relationships to review: e.g., "Okta user AWS IAM group memberships"

       • Narrow Scope: Choose specific data sources Veza has discovered.
   • Due date: Specify the Date (UTC) and Timezone when the review must be completed.

   • • Assign Reviewers: Assign default reviewers for all rows in the review.

     • Auto-assign reviewers: Assign row-level reviewers based on Veza metadata like managers or resource owners.

     • Fallback reviewers: Used when an auto-assignment is prevented or can't be found.
3. Click Create and Publish to make the results available to reviewers, or click Create to save a draft and preview the results.

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.

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. By attaching review creation rules to saved queries, you can trigger the creation of new reviews in response to changes in your authorization environment. This type of access review might be initiated whenever new user accounts are detected within an application, new entitlements are granted, a user's risk level increases, or if MFA is removed or disabled for an account.

On-demand reviews support Review Intelligence rules, and are created with a duration and reviewer assignments based on the rule configuration.

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.

• Review Creation Plans are rule settings that define how new reviews will be created.

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

• Creation Source: On the Access Reviews page, you can identify the source of a review by checking the Creation Source column. On-demand rules will have the source RULE_TRIGGERED.

Implementing On-Demand Reviews

Prerequisites

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

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

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

Add a Rule for On-Demand Reviews

To add a review creation rule:

1. Navigate to the saved query

2. Select "Manage Rules" from the actions menu

3. Click "Add New Rule"

4. Configure the rule details:

   • Name and description

   • Severity level

   • Trigger conditions

5. Click Action -> Create Review to open the review creation plan.

6. Configure the plan and save it.

7. Save the rule, and click Save again to finish modifying the query.

To configure the review creation plan

1. Click Configure New On-Demand Review

2. Select an existing review configuration

3. Set the duration for the review

4. Specify the reviewer assignment logic

5. Enable any Review Intelligence Rules

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

Rule Evaluation

• Rules are evaluated on a regular schedule aligned with data extraction intervals

• 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

Related Topics

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:

2. Alternate Manager Lookup Settings: When the primary lookup fails, the system can use one or more alternate IdP settings to find managers.

The lookup settings configuration includes:

• User Type: The type of user in the alternate IdP User, e.g., OAA.Oracle HCM.HRISEmployee

• User Identity Property: The property used to identify users across systems, e.g., customprop_manager_employee_number

• Manager Identity Property: The property containing the manager reference, e.g., customprop_manager_employee_number

• Instance Id Property: The property containing the instance ID, e.g., datasource_id

• Instance Id: The ID of the alternate IdP instance, e.g., 05bbc13d-bf25-45f2-ba09-03e5625a3b66

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.

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

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

The global IdP settings request takes an idp settings object for the primary IdP configuration, and one or more secondary IdPs defined in alternate_manager_lookup_settings

For example:

Overview

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

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

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

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

Effective and system permissions

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

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.

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:

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)

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

Policy inheritance and resource hierarchy

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

1. Create a configuration, and enable System mode

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

3. Expand Advanced Options > Summary Entities

4. Pick the entity types Folder, Organization, Project, IAM Policy, Role Binding, and Group Membership

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

Attribute filters on related entity properties

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

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

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

Overview

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

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

• Users with any access to an individual application.

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

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

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

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

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

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

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

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

Reference: Configuration Query Builder

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

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

Entity Type Groupings

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

Generic entity type groupings

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

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

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

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.

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.

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.

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

Configuring Digest Notifications

To configure Digest Notifications:

1. Navigate to Access Reviews > Settings.

2. Locate the Digest Notifications section.

Enabling Digest Notifications

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

Setting Normal Delivery

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

2. Choose the frequency:

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

   • 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

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

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

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.

• Unanimous Approval, Single Rejection: Both levels must approve for acceptance. A rejection at either level is final.

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. When enabled, reviewers at each level must approve the row before a decision is finalized.

1. First-Level Review

   • Starts upon creation of a multi-level review.

   • First-level reviewers can see and act on all assigned rows.

   • All rows must be signed off before the review progresses to the second level.

2. Second-Level Review

   • Begins after first-level reviews are complete.

   • By default, second-level reviewers only see rows approved by first-level reviewers. They may approve or reject previously approved rows but cannot change decisions on rows that were rejected at the first level.

Rejection at any level is final. Second-level reviewers do not sign off on access that a first-level reviewer rejected.

Notifications Behaviors for Reviewers in Multi-Level Reviews

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.

• If configured, completion notifications are sent to all reviewers.

Veza Actions in Multi-Level Reviews

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

1. Go to Access Reviews > Configurations and click New Review to create an access review.

2. Define the scope, set a due date, and assign initial reviewers.

3. In the Second Level Reviewers section, click Enable.

4. Assign specific reviewers, or auto-assign the user's manager, the resource's owner, or the first-level reviewer's manager.

6. Click Create and Publish to start the review (notifying reviewers), or Create to save it as a draft.

Multi-Level Approval in the Reviewer Interface

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.

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.

FAQs

• What happens if a row is rejected at the first level? The row is considered rejected and is hidden by default during second-level review.

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

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:

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.

• If all candidates are not allowed, Veza will try to assign alternate reviewers based on the selection method.

Changing the reviewer selection method

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

The Veza Customer Success team can change this global setting to enable any of the following selection methods. If the first selection method can find at least one allowed alternate reviewer, the user is assigned. Otherwise, the next selection method is attempted. Possible selection methods are:

• REVIEWERS_MANAGER | Assign the manager of the prevented candidate.

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

• WORKFLOW_CREATOR | Assign to the workflow creator.

• ADMIN | Assign to an arbitrary local Veza admin user.

For example, with the selection methods:

"value": {
    "selection_methods": [
        "REVIEWERS_MANAGER",
        "CERTIFICATION_ALTERNATE_REVIEWERS"
    ]
}

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

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

2. Otherwise, assign the first valid Fallback reviewer.

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

Overview

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

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

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

• “Approve previously approved and unchanged”

• “Rejected previously rejected and unchanged”

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

Add policies during review creation

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

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

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

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

Review intelligence action logs

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

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

Assign policies to some or all configurations

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

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 Webhooks for more information about supported targets.

Configuring Veza Actions

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

Events that can trigger Veza Actions:

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

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

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

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

Possible actions depend on the event:

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

• Email Notifications: Supports Approve Row and Reject Row.

• Jira: Supports Reject Row.

• ServiceNow: Supports Reject Row.

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

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

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

3. Toggle events that will trigger actions.

4. Pick a Veza Action for each event.

5. Save the configuration.

To configure Veza Actions for a 1-step review:

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

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

3. On the Review Details sidebar, find the Veza Actions section and click Configure Veza Actions.
4. Use the modal to assign or change the actions associated with different event types, and click Save when finished.

Lifecycle Management Auto-Revocation

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

Benefits:

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

• Supports all target apps supported by Lifecycle Management

• No custom integration - no webhooks

• To enable LCM integration, edit a review configuration and choose the Veza Action "Revoke access on Sign-off of Rejected Rows".

Requirements:

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

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

Implementation Considerations:

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

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

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

• Source and destination have to be entities from a common application, such as Active Directory for a review covering Active Directory Users to Active Directory Security Groups.

• Auto-revocation does not support heterogeneous scenarios, such as Okta Users to Snowflake Databases.

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

{
  "workflow_id": "ae68b59e-d5b8-45cf-9d73-644beef7c8a6",
  "workflow_name": "Access Review",
  "certification_id": "41ea28f2-fc3f-49fd-ac7c-8b85320a6d29",
  "message": "Certification completed",
  "requestor": "veza@veza.com"
}

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.

{
  "workflow_id": "b6a4e8ed-9bf9-4a5f-8545-cbe5e3e12702",
  "workflow_name": "User to Role to Github",
  "certification_id": "8e4de1b5-2045-4dd4-9844-3a4fbe3d0ad7",
  "certification_started_at": "2022-06-21T16:58:23Z",
  "certification_snapshot_id": 1655830200,
  "message": "1 row(s) rejected",
  "requestor": {
    "id": "e0c03c28-7999-4079-9d58-6cbcc314b85b",
    "name": "cookie.ai",
    "email": "cookie@cookie.ai"
  },
  "details": [
    {
      "result_id": 96,
      "source": {
        "canonical_name": "Brittany Smith",
        "datasource_id": "f9145343-2205-491a-b77a-7ac59bb5743d",
        "datasource_name": "Olympus",
        "department": "",
        "email": "bsmith@cookiebeta.ai",
        "guest": false,
        "id": "custom_provider:idp:f9145343-2205-491a-b77a-7ac59bb5743d:idp_type:olympus_idp:user:500044",
        "idp_type": "olympus_idp",
        "idp_unique_id": "500044",
        "is_active": true,
        "manager_email": "jharris@cookiebeta.ai",
        "manager_idp_unique_id": "500032",
        "manager_name": "jharris",
        "name": "bsmith",
        "property_five": "",
        "property_four": "",
        "property_one": "",
        "property_three": "",
        "property_two": "",
        "provider_id": "custom_idp_ctr01",
        "provider_name": "Custom_IDP_CTR01",
        "type": "CustomIDPUser"
      },
      "destination": {
        "application_type": "Github",
        "datasource_id": "5686863f-1628-41c5-a06d-b2c4f678d201",
        "description": "",
        "id": "custom_provider:application:5686863f-1628-41c5-a06d-b2c4f678d201:github_-_engineering:resource:repo01",
        "name": "repo01",
        "provider_id": "github",
        "provider_name": "GitHub",
        "resource_type": "repo",
        "type": "CustomResource"
      },
      "accumulated_effective_permissions": [
        "Read",
        "Write"
      ],
      "accumulated_raw_permissions": [
        "Fork",
        "Merge",
        "Pull",
        "Push"
      ],
      "updated_at": "2022-06-21T23:30:47.623828883Z",
      "updated_by": {
        "user_type": "localCookieUser",
        "id": "e0c03c28-7999-4079-9d58-6cbcc314b85b",
        "email": "cookie@cookie.ai",
        "name": "cookie.ai"
      },
      "waypoint": {
        "id": "custom_provider:application:5686863f-1628-41c5-a06d-b2c4f678d201:github_-_engineering:role:push:assignment:9",
        "name": "Push",
        "type": "CustomRoleAssignment"
      },
      "decision": "REJECTED",
      "notes": "this is the rejection note",
      "signed_off_state": "SIGNED_OFF"
    }
  ]
}

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

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

• Included entity attributes are: canonical_name, datasource_id, id, name, department, email, 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.

Tags and enrichment metadata

Tag example:

"tags": [
  {
    "key": "tag_one",
    "type": "VEZA",
    "value": ""
  },
  {
    "key": "tag_two",
    "type": "VEZA",
    "value": "value"
  }
]

Enrichment data example:

"joined_nodes": {
  "idp": {
      "canonical_name": "Ashley Abbott",
      "customprop_birthday": "1988-08-09T00:00:00Z",
      "customprop_cube": "D-jO452",
      "customprop_last_login": "2021-07-19T15:43:14Z",
      "datasource_id": "2691af72-b1d1-41ac-a714-ace1ae54d9a5",
      "datasource_name": "Custom IdP",
      "department": "",
      "email": "aabbott@cookiebeta.ai",
      "guest": false,
      "id": "custom_provider:idp:2691af72-b1d1-41ac-a714-ace1ae54d9a5:idp_type:custom_idp:user:507710",
      "identity_type": "HUMAN",
      "idp_unique_id": "507710",
      "is_active": true,
      "last_pushed_at": "2024-08-29T17:40:39Z",
      "manager_email": "wmccormick@cookiebeta.ai",
      "manager_idp_unique_id": "504975",
      "manager_name": "wmccormick",
      "name": "aabbott",
      "provider_id": "oaa_external:intuit-demo",
      "provider_name": "intuit-demo",
      "risk_score": 0,
      "tags": [],
      "type": "OAA.custom_idp.IDPUser"
  }
}