> 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-request/notifications.md).

# Notifications

Configure Veza Actions to send notifications about access request events and state changes to stakeholders.

## Overview

When Access Request events occur, such as a request being created, approved, or completed, Veza can send notifications using Veza Actions as pre-configured delivery channels.

These notifications enable organizations to alert approvers by email or Slack when requests require their attention, and notify requesters and beneficiaries of approval decisions. Notifications can also inform IT teams when provisioning completes or fails.

{% hint style="info" %}
**Configuration required**: Access Request notifications are opt-in. A tenant starts with an empty notification configuration: no event is enabled, no recipient is selected, and nothing is sent until an administrator creates a notification. See [Notification defaults](#notification-defaults).

Administrators configure Veza Actions to deliver notifications through email, Slack, or webhooks. Jira and ServiceNow are not supported as Access Request event notification channels. For ServiceNow ticket creation when access requests are submitted, see [ITSM Integration](/4yItIzMvkpAvMVFAamTf/features/access-request/configure-itsm-integration.md).
{% endhint %}

## How notifications work

Access Requests can trigger notifications to keep stakeholders informed about request status, approvals, and completion. These notifications are configured using **Veza Actions**, Veza's integration framework for sending event data to external systems.

When an Access Request event occurs (such as a request being created or a request state changing), Veza evaluates the configured Veza Action for the specific event type. Notifications are sent through the configured integration or by email. Recipients receive notifications with request details and context, which you can customize with HTML templates.

For complete information about configuring Veza Actions and notification delivery channels, see [Veza Actions](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications.md).

## Access Request events

The following events can trigger notifications when they occur during the Access Request lifecycle:

| Event                 | API value                          | Occurs when                                                                   | Default |
| --------------------- | ---------------------------------- | ----------------------------------------------------------------------------- | ------- |
| **Request Created**   | `ACCESS_REQUEST_CREATED`           | Request is initiated                                                          | Off     |
| **Action Run**        | `ACCESS_REQUEST_ACTION_RUN`        | Access plan execution begins                                                  | Off     |
| **State Changed**     | `ACCESS_REQUEST_STATE_CHANGED`     | Request transitions between states (Initial, Waiting for Approval, and so on) | Off     |
| **Approver Assigned** | `ACCESS_REQUEST_APPROVER_ASSIGNED` | New approvers are assigned to the request                                     | Off     |
| **Request Completed** | `ACCESS_REQUEST_COMPLETED`         | Request is successfully fulfilled                                             | Off     |
| **Request Failed**    | `ACCESS_REQUEST_FAILED`            | Request execution fails                                                       | Off     |

{% hint style="info" %}
These events are shared with the Lifecycle Management event system. See [Lifecycle Management Notification Templates](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.md) for the complete list of available events and their API usage values.
{% endhint %}

## Notification defaults

Every event in the table above is off until an administrator turns it on. A tenant is created with an empty Access Request notification configuration, so in a new tenant:

* No event sends anything, on any channel.
* No recipient class is selected, and no custom email address is configured.
* Each event uses the default email template Veza supplies for it, until an administrator customizes one.

The same holds inside a single notification. A new notification form opens with every recipient checkbox cleared, and validation requires at least one recipient before the notification can be saved.

{% hint style="warning" %}
**Two email sends do not consult the recipient settings.** Both are unconditional, and neither requires its recipient class to be enabled for the event:

* **The beneficiary of an on-behalf request** is emailed on **Request Created**, **Request Completed**, and **Request Failed**, whether or not the Beneficiary recipient is enabled for those events. Every other event follows the configuration.
* **A newly assigned or reassigned approver** is emailed about the assignment, whether or not the Approvers recipient is enabled.

There is no equivalent send for the **Creator**. A requester who submits on someone else's behalf receives nothing for an event unless the Creator recipient is enabled on it, including **Request Completed**, where the beneficiary is emailed and the requester is not. To notify requesters when their on-behalf requests complete, enable the Creator recipient on that event explicitly.
{% endhint %}

## Notification delivery channels

Access Request notifications can be delivered through email and Slack channels. Each delivery method has specific capabilities and configuration requirements:

### Email notifications

Send customizable email notifications to approvers, requesters, beneficiaries, watchers, and custom email addresses. Email templates support HTML formatting and dynamic placeholders for request details. See [Veza Actions](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications.md) for setup instructions.

### Slack integration

There are two options for Slack notifications:

* **Slack App** (recommended for approver notifications): Sends direct messages to approvers, with a native Slack integration with rich formatting. This Action is restricted to approver notifications only.
* **Slack Webhooks** (for channel notifications): Post a single formatted message to a Slack channel. The message content is the same regardless of which recipients are selected; Slack Webhook notifications are not tailored or delivered per recipient.

See [Slack App Notifications](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/slack-app.md) and [Slack Webhook](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications/destinations/slack.md) for configuration details.

### Webhook payload structure

Slack Webhook notifications post a formatted message to the channel: a Slack Block Kit message showing the request's creator, ID, event, and state, with a link to the request in Veza.

Webhook actions that deliver raw JSON receive the event type and request details in this shape:

```json
{
  "eventType": "ACCESS_REQUEST_COMPLETED",
  "accessRequest": {
    "id": "request-uuid",
    "state": "COMPLETED",
    "assigneeEntityName": "beneficiary@example.com",
    "targetEntityNames": ["Engineering-Team"]
  }
}
```

## Configuring notifications

### Configuration requirements

The setup process differs based on your chosen notification channel:

**Email Notifications**

* No prerequisite setup required
* Configure recipients and templates directly when creating the notification
* Start immediately with step 2 below

**Slack Notifications**

* Requires preconfigured Veza Actions (Slack Webhook or Slack App)
* See [Veza Actions](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications.md) for integration-specific setup instructions
* Complete Veza Action setup before proceeding to step 2

### Configuration steps

To configure notifications for Access Request events:

1. **For Slack only**: Create Veza Actions for your Slack integration
   * [Slack App](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/slack-app.md) for direct messages to approvers
   * [Slack Webhook](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications/destinations/slack.md) for channel notifications
2. Navigate to **Lifecycle Management** > **Settings** > **Access Request Settings**
3. Scroll to **Notifications** and select **Create Notification**
4. Select the event type that triggers the notification (for example, Request Created or State Changed)
5. Choose your notification method and configure it:
   * **Email**: Select at least one recipient (**Approvers**, **Requesters**, **Beneficiaries**, **Watchers**, or custom addresses) and an email template. Every checkbox starts cleared, and the notification cannot be saved with no recipient selected.
   * **Slack Webhook**: Choose preconfigured webhook action (posts to channels)
   * **Slack App**: Choose preconfigured app action (direct messages to approvers only)
6. **Save** the notification configuration

{% hint style="success" %}
You can configure multiple notifications for the same event type using different channels or recipients. For example, you might both email the requester and post to a Slack channel when requests are approved.
{% endhint %}

### Recipient configuration

Notification Recipients determine who receives notifications for each event type based on their role in the access request:

| Recipient         | API field        | Description                                                 | Default | Per-recipient delivery |
| ----------------- | ---------------- | ----------------------------------------------------------- | ------- | ---------------------- |
| **Approvers**     | `to_approvers`   | Users assigned to approve the request                       | Off     | Email                  |
| **Creator**       | `to_creator`     | User who submitted the request                              | Off     | Email                  |
| **Beneficiary**   | `to_beneficiary` | User who receives the access                                | Off     | Email                  |
| **Watchers**      | `to_watchers`    | Users subscribed to receive notifications about the request | Off     | Email                  |
| **Custom emails** | `other_emails`   | Additional email addresses                                  | Empty   | Email                  |

In the console, the recipient checkboxes are labeled **Approvers**, **Requesters**, **Beneficiaries**, and **Watchers**. **Requesters** corresponds to the Creator recipient in the table above and to the `to_creator` API field.

Recipients are configured per event type. For example, you might enable **Approver Assigned** notifications only for approvers, **Request Completed** notifications for both the creator and the beneficiary, and route **Request Failed** notifications to IT teams through a Slack channel.

Enabling **Beneficiary** also emails the beneficiary's managers, and enabling **Creator** also emails the requester's managers. Manager copies are resolved from the manager attribute on the Lifecycle Management identity, so a recipient whose identity carries no manager produces no additional email, and a recipient who carries several managers produces one copy for each.

The beneficiary's managers are copied on every event the Beneficiary recipient is enabled for. The requester's managers are copied in every case except one: on a request submitted on behalf of someone else, while the tenant's [Request on behalf of others](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#request-on-behalf-of-others) setting is **Everyone**, they are dropped. Under that setting a requester need not be related to the beneficiary at all, so copying their management chain on somebody else's access would disclose it to people with no part in the request. Under the default **Managers only** setting the requester is the beneficiary's manager, so the copy is kept.

Nobody receives two copies of the same notification: an address that falls into several recipient classes is emailed once, with the wording for the most specific role.

{% hint style="info" %}
**Recipient selection applies to email.** The Slack and webhook channels do not read the recipient checkboxes. Each sends one message per event to its own configured target:

* A **Slack Webhook** posts one message to its channel.
* A **generic webhook** posts one payload to its endpoint.
* The **Slack App** sends direct messages to the request's current approvers.

The recipient checkboxes stay visible when a Slack or webhook channel is selected, but changing them does not change what those channels deliver.
{% endhint %}

### Recipients for self-service and on-behalf requests

Access requests have two modes, and notification recipients resolve differently in each:

* **Self-service**: the requester and beneficiary are the same person (first-party request).
* **On behalf of someone else**: the requester creates the request for a different beneficiary (third-party request). See [Requester versus Beneficiary](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md#requester-versus-beneficiary).

For a **self-service** request, the **Creator** and **Beneficiary** recipients resolve to the same person, so a single notification is sent per event. Each recipient is notified only when its recipient type is enabled for that event. Custom email addresses are included on every configured event.

For an **on-behalf** request, notifications are tailored to each recipient's role, and the message reflects who requested the access and for whom:

| Recipient                          | When notified on an on-behalf request                                                                                                                                                                                                                                                                                                                       |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Beneficiary**                    | Notified on **Request Created**, **Request Completed**, and **Request Failed** whether or not the Beneficiary recipient is enabled for that event. For other events, notified only when the Beneficiary recipient is enabled.                                                                                                                               |
| **Creator** (requester)            | Notified only when the Creator recipient is enabled for the event. If it is not enabled, the requester receives no notification for that event.                                                                                                                                                                                                             |
| **Approvers**                      | Notified when the Approvers recipient is enabled. In addition, an approver who is newly assigned or reassigned to the request (for example, by an administrator, or when a blocked request is reassigned) is emailed whether or not the Approvers recipient is enabled. Delegated approvers additionally see which approver the request was delegated from. |
| **Watchers** and **Custom emails** | Watchers are notified when the Watchers recipient is enabled. Custom email addresses are included on every configured event.                                                                                                                                                                                                                                |

A newly assigned or reassigned approver receives a personalized message naming the person who assigned them. That message replaces every other copy of the notification they would have received for the event: Veza removes their address from all of the recipient groups above, including Creator, Beneficiary, Approvers, Watchers, and custom email addresses. Someone who belongs to more than one of those groups still receives a single email.

{% hint style="info" %}
Per-recipient tailoring, the unconditional beneficiary notification, and the unconditional notification to a newly assigned approver apply to **email** notifications. Slack and webhook channels post a single message per event without per-recipient variation.
{% endhint %}

#### Example: an on-behalf request

A manager (the **requester**) requests an application bundle for a new team member (the **beneficiary**). With **Request Created**, **Request Completed**, and **Request Failed** notifications configured:

* The **beneficiary** is emailed when the request is created and again when it completes. Those events notify the beneficiary regardless of the recipient settings.
* The **requester** is emailed on those same events only if the **Creator** recipient is enabled; otherwise the requester is not notified.
* An **approver** is emailed when assigned, if the **Approvers** recipient is enabled.
* A security-team Slack channel receives a message on completion through a **Slack Webhook** recipient.

## Email template placeholders

When creating custom email templates for Access Request notifications, you can reference the following dynamic placeholders to include information about the specific request:

### Request information

| Placeholder                      | Description                                                      |
| -------------------------------- | ---------------------------------------------------------------- |
| `{{ACCESS_REQUEST_URL}}`         | Direct link to view the request in Veza                          |
| `{{ACCESS_REQUEST_STATE}}`       | Current state, for example `WAITING_FOR_APPROVAL` or `COMPLETED` |
| `{{ACCESS_REQUEST_TYPE}}`        | GRANT or REVOKE                                                  |
| `{{ACCESS_REQUEST_SOURCE_TYPE}}` | How the request was initiated                                    |

### Entity information

| Placeholder                      | Description                    |
| -------------------------------- | ------------------------------ |
| `{{ACCESS_REQUEST_ENTITY_NAME}}` | Name of the beneficiary        |
| `{{ACCESS_REQUEST_ENTITY_TYPE}}` | Type of the beneficiary entity |

### Target information

| Placeholder                      | Description                 |
| -------------------------------- | --------------------------- |
| `{{ACCESS_REQUEST_TARGET_NAME}}` | Name of the target resource |
| `{{ACCESS_REQUEST_TARGET_TYPE}}` | Type of the target resource |

### Error information

| Placeholder               | Description                           |
| ------------------------- | ------------------------------------- |
| `{{EVENT_ERROR_MESSAGE}}` | Detailed error message from the event |

For a full list of available placeholders across all Access Request and Lifecycle Management events, see [Notification Templates: Placeholders](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.md#placeholders).

## Default email templates

Veza provides default email templates for each Access Request event type. These templates use the placeholders listed above and can be customized to match your organization's requirements.

### Example: Request Created

**Subject:** `{{ACCESS_REQUEST_SOURCE_TYPE}} for {{ACCESS_REQUEST_ENTITY_NAME}} is {{ACCESS_REQUEST_STATE}}`

**Body:**

```html
<html><body>
Hello,<br>
<br>
The request is currently in {{ACCESS_REQUEST_STATE}} state.
<br>
For details: {{ACCESS_REQUEST_URL}}
<br>
</body></html>
```

### Example: Request Failed

**Subject:** `{{ACCESS_REQUEST_SOURCE_TYPE}} for {{ACCESS_REQUEST_ENTITY_NAME}} is failed`

**Body:**

```html
<html><body>
Hello,<br>
<br>
The request is failed, with an error message: {{EVENT_ERROR_MESSAGE}}
<br>
For details: {{ACCESS_REQUEST_URL}}
<br>
</body></html>
```

To view all default templates and create custom templates, see [Lifecycle Management Notification Templates: Default Template Content](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.md#default-template-content).

## General guidelines for Access Request notifications

### Target notifications strategically

Enable notifications for stakeholders who need to act on or be informed about specific events. This means thoughtfully determining how:

* **Approvers** are notified of new assignments and reminders in a timely manner
* **Requesters** are aware of approval decisions and completion status
* **Beneficiaries** receive confirmations of access granted
* **IT Teams** can track and respond to provisioning failures, technical issues

Review the default templates for each event type, and customize them to include relevant links, instructions, and branding so that expectations and next steps are clear. Keep templates simple and actionable.

### Use appropriate channels

Match notification channels to your audience. Remember that without enabling email notifications, no alerts are sent by default. Configure the appropriate Veza Actions based on the audience and event type. Your organization's structure will also dictate who is involved in requests and approvals, and how they should be informed of decisions and state changes.

* **Email**: Enable for end users, executives, and external stakeholders for visibility
* **Slack direct messages**: Individual approvers who need to respond swiftly
* **Slack channels**: For IT teams, security teams, and operational groups for tracking and discussion

Contact your Veza customer support team if additional integrations are required for your use case.

### Test before production

Before enabling notifications for all users:

1. Verify connectivity by testing the Veza Action when configuring the downstream integration
2. Configure and trigger a test action with limited recipients
3. Review the template formatting and placeholder values (see the API documentation for endpoints to send test emails)
4. Verify recipient lists are as expected

After implementing notifications, review activity to confirm that notifications continue to deliver successfully and that templates render correctly.

## Related documentation

* [Veza Actions](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications.md): Complete guide to configuring notification delivery channels
* [Lifecycle Management Notification Templates](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.md): Managing email templates and placeholders
* [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md): Configuring Access Request notification settings
* [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md): Understanding request lifecycle and state transitions
* [Managing Access Requests](/4yItIzMvkpAvMVFAamTf/features/access-request/request-manage-access.md): How to add watchers to requests for notifications


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.