> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/veza-actions.md). # Veza Actions for Access Reviews Enable third-party integrations or custom webhooks for Veza Access Reviews. ### Overview Veza Actions enable external processes when decisions and other events occur during an access review. Actions might trigger automated remediation, or announce to a team when a row is rejected, reviewers change, or the review is complete. For example, you can use Veza to create a Jira issue or ServiceNow ticket for rejected access, or trigger actions in a custom application using a webhook. To enable Veza Actions for a configuration or review, an administrator will need to configure integrations. See [Veza Actions](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications.md) and [Custom Webhooks](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications/destinations/webhooks.md) for more information about supported targets. {% hint style="info" %} **Slack and Microsoft Teams in Access Reviews**: Review notifications and reminders reach reviewers in Slack or Microsoft Teams as direct messages, through the [Slack App](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/slack-app.md) and [Teams App](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications/destinations/teams-app.md) integrations. Configure them in the notification settings of a configuration. Slack webhook Veza Actions can't be selected for Access Review events. To post review events to a Microsoft Teams channel, use a [Teams webhook](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications/destinations/teams.md), which is listed with the webhooks. {% endhint %} ### 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." * **Edit notes**: When a user edits the notes on a row. * **Mark as fixed**: When a row is marked as fixed. * **Review created**, **Review published**, and **Review expired**: When a review is created, published, or expires. Possible actions depend on the event: * **Webhooks**: Supports every event. * **Microsoft Teams** webhooks: Supports every event. They are listed with the webhooks. See [Microsoft Teams Integration](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications/destinations/teams.md) for detailed setup instructions. * **Email Notifications**: Supports *Approve Row* and *Reject Row*. * **Jira**: Supports *Reject Row*. * **ServiceNow**: Supports *Reject Row*. * **Custom REST Payload** (Early Access): Supports *Reject Row*. See [Custom REST Payload](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/custom-rest-payload.md). 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 one or more Veza Actions 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**. ![Use the details sidebar to configure notifications or edit Veza Actions for a single review.](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-6dcf4a4cac25c19721f35c2db74afae8f905fc69%2Freview-details-veza-actions.png?alt=media) 4. Use the modal to assign or change the actions associated with different event types, and click **Save** when finished. ### Auto-revocation The **Revoke access of rejected row on sign-off** option in the Veza Actions section enables auto-revocation. When configured, signing off on a rejected row automatically removes the user from the target entitlement — no webhook or custom integration required. For full details including requirements, supported integrations, and scope constraints, see [Auto-revocation](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/auto-revocation.md). ### Webhook payload Access review events can trigger a JSON payload sent to an external listener, which parses the payload to trigger remediation actions. Each payload includes the configuration (`workflow`) name and ID, the review (`certification`) ID, and the event `message`. Row events add `details` about the row, and the review created, published, and expired events add the review name, dates, and counts. 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 ```json { "workflow_id": "ae68b59e-d5b8-45cf-9d73-644beef7c8a6", "workflow_name": "Access Review", "certification_id": "41ea28f2-fc3f-49fd-ac7c-8b85320a6d29", "certification_started_at": "2026-10-27T15:00:00Z", "certification_snapshot_id": 1761650000, "message": "Certification completed", "completion_summary": "", "requestor": { "id": "5f0c2a8e-3b1d-4c7a-9e62-0d8f4b7a1c35", "name": "Alex Rivera", "email": "alex.rivera@example.com" } } ``` | Field | Type | Description | | --------------------------- | ------- | -------------------------------------------------------------------------------------------------- | | `workflow_id` | UUID | A unique identifier for the review configuration. | | `workflow_name` | String | The name of the review configuration. | | `certification_id` | UUID | A unique identifier for the review. | | `certification_started_at` | String | When a user or a schedule requested the review, in RFC 3339 format. | | `certification_snapshot_id` | Integer | The ID of the graph snapshot that the review query used, or `0` when the review used current data. | | `message` | String | A summary message describing the event. | | `completion_summary` | String | The summary recorded when the review was completed. Empty when no summary was entered. | | `requestor` | Object | The `id`, `name`, and `email` of the user who completed the review. | #### Example webhook: review created, published, or expired The **Review created**, **Review published**, and **Review expired** events send a webhook payload that shares one set of fields. **Review published** adds `published_at`, and **Review expired** adds `published_at`, `expired_at`, `expired_level`, and `expiration_behavior`. Veza sends **Review expired** each time a review expires, at any approval level. At the final level, Veza sends it after the configured expiration behavior runs on the rows without a decision. ```json { "workflow_id": "ae68b59e-d5b8-45cf-9d73-644beef7c8a6", "workflow_name": "Access Review", "certification_id": "41ea28f2-fc3f-49fd-ac7c-8b85320a6d29", "certification_name": "Access Review - Q4", "certification_snapshot_id": 1761650000, "message": "Review published", "requestor": { "id": "5f0c2a8e-3b1d-4c7a-9e62-0d8f4b7a1c35", "name": "Alex Rivera", "email": "alex.rivera@example.com" }, "created_at": "2026-10-27T15:00:00Z", "due_date": "2026-11-10T23:59:59Z", "total_approval_levels": 2, "review_url": "https://example.vezacloud.com/app/workflows/certification/41ea28f2-fc3f-49fd-ac7c-8b85320a6d29?tab=assigned", "total_rows": 1250, "published_at": "2026-10-27T15:12:40Z" } ``` | Field | Type | Events | Description | | --------------------------- | ------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `workflow_id` | UUID | All | A unique identifier for the review configuration. | | `workflow_name` | String | All | The name of the review configuration. | | `certification_id` | UUID | All | A unique identifier for the review. | | `certification_name` | String | All | The name of the review. | | `certification_snapshot_id` | Integer | All | The ID of the graph snapshot that the review query used, or `0` when the review used current data. | | `message` | String | All | `Review created`, `Review published`, or `Review expired`. | | `requestor` | Object | All | The `id`, `name`, and `email` of the user who triggered the event. For **Review expired**, this is the Veza system user, with the fixed values `SystemUserId`, `SystemUser`, and `no-reply@veza.com`. | | `created_at` | String | All | When a user or a schedule requested the review. | | `due_date` | String | All | The due date of the review's final approval level. | | `total_approval_levels` | Integer | All | The number of approval levels in the review. | | `review_url` | String | All | A link to the review in Veza. | | `total_rows` | Integer | All | The number of rows in the review. | | `published_at` | String | Published, expired | When the review was published. | | `expired_at` | String | Expired | When the review expired. | | `expired_level` | Integer | Expired | The approval level the review was at when it expired, starting at 1. | | `expiration_behavior` | String | Expired | The expiration behavior applied to rows without a decision. Final approval level only. | `expiration_behavior` is one of `DO_NOTHING`, `AUTO_REJECT_INCOMPLETE_RESULTS`, or `AUTO_APPROVE_INCOMPLETE_RESULTS` (see [Review Expiration Behavior](/4yItIzMvkpAvMVFAamTf/developers/api/workflows/access-review-settings/reviewexpirationbehavior.md)). It is present only when the review expired at its final approval level. Timestamps use RFC 3339 format and are empty strings when not set. #### 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. ```json { "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 The `AwfResult` preview API object includes tags and [enrichment data](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/enrich-idp-hris.md) if these options are enabled in the review configuration. Webhook payload `details` also include these fields: Tag example: ```json "tags": [ { "key": "tag_one", "type": "VEZA", "value": "" }, { "key": "tag_two", "type": "VEZA", "value": "value" } ] ``` Enrichment data example: ```json "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" } } ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/veza-actions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.