> 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/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.md). # Notifications Customizing email notifications and Webhook configuration for Lifecycle Management events and Access Requests. ### Email Templates Overview Administrators can customize email notifications sent during Lifecycle Management and Access Request workflows. These emails can include instructions, unique branding, and placeholders for metadata specific to the event (such as entity names, action types, or request details). Each notification type (usage) can have its own customized template. Notification templates support HTML and CSS. They can include links to external images or you can upload small files to Veza. This document includes steps to configure templates in the Veza UI or the Notification Templates API, and a reference for event types, default templates, and supported placeholders. {% hint style="info" %} **Template Management**: You can manage notification templates in the Veza UI (**Lifecycle Management** > **Settings** > **Notifications**) or through the Notification Templates API. {% endhint %} {% hint style="info" %} **Access Reviews Notification Templates**: For access review workflow notifications, see [Access Reviews Notification Templates](/4yItIzMvkpAvMVFAamTf/developers/api/notification-templates.md). {% endhint %} ### Custom Email Templates In addition to event-specific templates, you can create **custom email templates** that are not tied to specific lifecycle events. These reusable templates allow you to define notification content once and use it across Send Notification actions, action notification settings, and policy notifications. Custom email templates are: * **Reusable**: Single template for multiple workflows and actions * **Event-independent**: Not associated with a specific lifecycle event type * **Flexible**: Can be used in Send Notification actions, action notification settings, and policy notifications * **Standard placeholder support**: Supports the standard placeholders. Which ones are filled depends on where the template is used To create a custom email template: 1. Navigate to **Lifecycle Management** > **Settings** > **Notifications** 2. Click **Create Template** 3. Select **For custom mail** (as opposed to "For event") 4. Define your template name, subject, and body using HTML and placeholders 5. Save the template To use a custom template, select it in **Select Email Template** when you configure an email notification: * **Send Notification action**: in the action's settings * **Action Notification Settings**: in the notification on an action. One selection applies to every outcome you check under **Send a notification if:** * **Policy notification**: in the notification under **Policy Settings** > **Notifications** When you select **Default template**, the template depends on where the notification is configured. A policy notification uses the template for its event. The Send Notification action and Action Notification Settings use your organization's default **Action Succeeded** or **Action Failed** template, if one is set, and otherwise the action's built-in template. See [Template selection order](#template-selection-order). When you select a custom template, that template is used regardless of the specific event being processed. {% hint style="info" %} Custom templates support all standard placeholders documented in the [Placeholders](#placeholders) section. The available values depend on the context in which the template is used (e.g., action notifications have action-related placeholders, event notifications have event-related placeholders). {% endhint %} ### Default Templates The system provides built-in templates for all Lifecycle Management and Access Request events. These templates use placeholders that are automatically replaced with actual values when notifications are sent. **Generic Failure Template** When specific event templates aren't available or when events fail, the system uses a generic failure template: **Subject**: `Lifecycle job {{EVENT_TYPE}} has failed` **Body**: ```html

Here is the notification that lifecycle job has failed.
Error message: {{EVENT_ERROR_MESSAGE}}

For reference:
job_id: {{JOB_ID}}

identity_id: {{EVENT_IDENTITY_ID}}
identity_name: {{EVENT_IDENTITY_NAME}}
entity_type: {{ENTITY_TYPE}}
entity_name: {{ENTITY_NAME}} ``` See [Default Template Content](#default-template-content) for all default messages. **Lifecycle Management Events** Each template you create is associated with a specific notification event (referred to as `usage` in the API). The following event types are available for Lifecycle Management workflows, organized by functional area:
Identity Management Events | Event Type | API Usage Value | Description | | ----------------------------- | ---------------------------------------------------- | ------------------------------------------------------------- | | Create Identity | `LIFECYCLE_MANAGEMENT_CREATE_IDENTITY` | Sent when a new identity/account is created | | Create Identity Failed | `LIFECYCLE_MANAGEMENT_CREATE_IDENTITY_FAILED` | Sent when identity creation fails | | Sync Identity | `LIFECYCLE_MANAGEMENT_SYNC_IDENTITY` | Sent when an identity is synchronized | | Sync Identity Failed | `LIFECYCLE_MANAGEMENT_SYNC_IDENTITY_FAILED` | Sent when identity sync fails | | Delete Identity | `LIFECYCLE_MANAGEMENT_DELETE_IDENTITY` | Sent when an identity is deleted | | Delete Identity Failed | `LIFECYCLE_MANAGEMENT_DELETE_IDENTITY_FAILED` | Sent when identity deletion fails | | Disable Identity | `LIFECYCLE_MANAGEMENT_DISABLE_IDENTITY` | Sent when an identity is disabled | | Disable Identity Failed | `LIFECYCLE_MANAGEMENT_DISABLE_IDENTITY_FAILED` | Sent when identity disabling fails | | Create Guest Account | `LIFECYCLE_MANAGEMENT_CREATE_GUEST_ACCOUNT` | Sent when a guest account is created | | Create Guest Account Failed | `LIFECYCLE_MANAGEMENT_CREATE_GUEST_ACCOUNT_FAILED` | Sent when guest account creation fails | | Identity Deleted From Sources | `LIFECYCLE_MANAGEMENT_IDENTITY_DELETED_FROM_SOURCES` | Sent when an identity is deleted from its connected source(s) | **Identity Deleted From Sources** covers identities removed from a source through normal processing. It does **not** fire for records dropped by a [Duplicate Resolution Rule](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/duplicate-resolution.md), which are hard-deleted without emitting an event.
Relationship Management Events | Event Type | API Usage Value | Description | | -------------------------- | ------------------------------------------------- | ------------------------------------------------ | | Add Relationship | `LIFECYCLE_MANAGEMENT_ADD_RELATIONSHIP` | Sent when a relationship is added | | Add Relationship Failed | `LIFECYCLE_MANAGEMENT_ADD_RELATIONSHIP_FAILED` | Sent when adding relationship fails | | Remove Relationship | `LIFECYCLE_MANAGEMENT_REMOVE_RELATIONSHIP` | Sent when a relationship is removed | | Remove Relationship Failed | `LIFECYCLE_MANAGEMENT_REMOVE_RELATIONSHIP_FAILED` | Sent when removing relationship fails | | Remove Direct Access | `LIFECYCLE_MANAGEMENT_REMOVE_DIRECT_ACCESS` | Sent when direct access to a resource is removed |
Email Management Events | Event Type | API Usage Value | Description | | ----------------------- | ---------------------------------------------- | ------------------------------- | | Create Email | `LIFECYCLE_MANAGEMENT_CREATE_EMAIL` | Sent when an email is created | | Create Email Failed | `LIFECYCLE_MANAGEMENT_CREATE_EMAIL_FAILED` | Sent when email creation fails | | Write Back Email | `LIFECYCLE_MANAGEMENT_WRITE_BACK_EMAIL` | Sent when email is synced back | | Write Back Email Failed | `LIFECYCLE_MANAGEMENT_WRITE_BACK_EMAIL_FAILED` | Sent when email sync back fails |
Password Management Events | Event Type | API Usage Value | Description | | ---------------------- | --------------------------------------------- | ------------------------------- | | Change Password | `LIFECYCLE_MANAGEMENT_CHANGE_PASSWORD` | Sent when a password is changed | | Change Password Failed | `LIFECYCLE_MANAGEMENT_CHANGE_PASSWORD_FAILED` | Sent when password change fails | | Reset Password | `LIFECYCLE_MANAGEMENT_RESET_PASSWORD` | Sent when a password is reset | | Reset Password Failed | `LIFECYCLE_MANAGEMENT_RESET_PASSWORD_FAILED` | Sent when password reset fails |
Entitlement Management Events | Event Type | API Usage Value | Description | | ------------------------- | ------------------------------------------------ | ------------------------------------ | | Create Entitlement | `LIFECYCLE_MANAGEMENT_CREATE_ENTITLEMENT` | Sent when an entitlement is created | | Create Entitlement Failed | `LIFECYCLE_MANAGEMENT_CREATE_ENTITLEMENT_FAILED` | Sent when entitlement creation fails | | Rename Entitlement | `LIFECYCLE_MANAGEMENT_RENAME_ENTITLEMENT` | Sent when an entitlement is renamed | | Rename Entitlement Failed | `LIFECYCLE_MANAGEMENT_RENAME_ENTITLEMENT_FAILED` | Sent when entitlement renaming fails | | Sync Entitlement | `LIFECYCLE_MANAGEMENT_SYNC_ENTITLEMENT` | Sent when an entitlement is synced | | Sync Entitlement Failed | `LIFECYCLE_MANAGEMENT_SYNC_ENTITLEMENT_FAILED` | Sent when entitlement sync fails |
Actions and Workflows Events | Event Type | API Usage Value | Description | | ----------------------- | ---------------------------------------------- | -------------------------------------- | | Custom Action | `LIFECYCLE_MANAGEMENT_CUSTOM_ACTION` | Sent when a custom action is performed | | Custom Action Failed | `LIFECYCLE_MANAGEMENT_CUSTOM_ACTION_FAILED` | Sent when custom action fails | | Action Succeed | `LIFECYCLE_MANAGEMENT_ACTION_SUCCEED` | Sent when an action succeeds | | Action Failed | `LIFECYCLE_MANAGEMENT_ACTION_FAILED` | Sent when an action fails | | Workflow Task Failed | `LIFECYCLE_MANAGEMENT_WORKFLOW_TASK_FAILED` | Sent when a workflow task fails | | Extraction Event Failed | `LIFECYCLE_MANAGEMENT_EXTRACTION_EVENT_FAILED` | Sent when extraction processing fails |
Access Reviews Events | Event Type | API Usage Value | Description | | --------------------------- | -------------------------------------------------- | ---------------------------------- | | Create Access Review Queued | `LIFECYCLE_MANAGEMENT_CREATE_ACCESS_REVIEW_QUEUED` | Sent when access review is queued | | Create Access Review | `LIFECYCLE_MANAGEMENT_CREATE_ACCESS_REVIEW` | Sent when access review is created |
Safety Events | Event Type | API Usage Value | Description | | --------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Safety Limit Reached | `LIFECYCLE_MANAGEMENT_SAFETY_LIMIT_REACHED` | Sent when any safety limit is reached: a Hard Limit or a Predictive Safety Limit, at the policy or workflow level. The event message says which limit was reached | | Invalid Identities Detected | `LIFECYCLE_MANAGEMENT_INVALID_IDENTITIES_DETECTED` | Sent when invalid identities are detected during policy execution |
Access Request Events | Event Type | API Usage Value | Description | | -------------------------------- | ------------------------------------------------------- | ---------------------------------------------- | | Access Request Created | `LIFECYCLE_MANAGEMENT_ACCESS_REQUEST_CREATED` | Sent when an Access Request is created | | Access Request Action Run | `LIFECYCLE_MANAGEMENT_ACCESS_REQUEST_ACTION_RUN` | Sent when Access Request actions start running | | Access Request State Changed | `LIFECYCLE_MANAGEMENT_ACCESS_REQUEST_STATE_CHANGED` | Sent when Access Request state changes | | Access Request Approver Assigned | `LIFECYCLE_MANAGEMENT_ACCESS_REQUEST_APPROVER_ASSIGNED` | Sent when new approvers are assigned | | Access Request Succeed | `LIFECYCLE_MANAGEMENT_ACCESS_REQUEST_SUCCEED` | Sent when Access Request succeeds | | Access Request Failed | `LIFECYCLE_MANAGEMENT_ACCESS_REQUEST_FAILED` | Sent when Access Request fails |
Non-Human Identity (NHI) Events | Event Type | API Usage Value | Description | | ---------- | --------------------------------- | --------------------------------------------- | | Rotate Key | `LIFECYCLE_MANAGEMENT_ROTATE_KEY` | Sent when a Non-Human Identity key is rotated |
### Default Template Content Veza provides built-in email templates for all event types, organized by functional area below. These templates include standard placeholders and can be customized or replaced with your own templates.
Identity Management Templates **CREATE\_IDENTITY** * **Subject**: `New Hire Notification: {{ENTITY_TYPE}} account created` * **Body**: ```html Hello,

Here is the information for your new-hire: {{ENTITY_NAME}}

Account Type: {{ENTITY_TYPE}}
Login Name: {{LOGIN_NAME}}

``` **CREATE\_GUEST\_ACCOUNT** * **Subject**: `New {{ENTITY_TYPE}} Guest Account Created: {{ENTITY_NAME}}` * **Body**: ```html Hello,

New {{ENTITY_TYPE}} Guest Account Created

Account Type: {{ENTITY_TYPE}}
Name: {{ENTITY_NAME}}
Login Name: {{LOGIN_NAME}}
Invite Sent: {{SENT_INVITE}}

``` **SYNC\_IDENTITY** * **Subject**: `Sync Identity Notification: {{ENTITY_TYPE}} account synced` * **Body**: ```html Hello,

{{ENTITY_NAME}} attributes have been synced

Account Type: {{ENTITY_TYPE}}

``` **DELETE\_IDENTITY** * **Subject**: `Identity Deleted Notification: {{ENTITY_TYPE}} has an account deleted` * **Body**: ```html Hello,

{{ENTITY_NAME}} has been deleted

Account Type: {{ENTITY_TYPE}}

``` **DISABLE\_IDENTITY** * **Subject**: `Identity Disabled Notification: {{ENTITY_TYPE}} has an account disabled` * **Body**: ```html Hello,

{{ENTITY_NAME}} has been disabled

Account Type: {{ENTITY_TYPE}}

``` **IDENTITY\_DELETED\_FROM\_SOURCES** * **Subject**: `Action Required - Identity Deleted: {{FULL_NAME}}` * **Body**: ```html Hello,
An identity has been deleted from the identity source(s). User accounts previously provisioned in connected systems may require review and cleanup.

Systems with Provisioned Accounts ({{SYNCED_ENTITY_COUNT}}):
{{SYNCED_ENTITY_LIST}}

Required Actions:
  1. Navigate to the identity in Veza
  2. Review the provisioned accounts displayed for this identity
  3. Run deprovisioning workflows to remove or disable dormant accounts

Identity Details:
Name: {{FULL_NAME}}
Email: {{EMAIL}}
Employee ID: {{EMPLOYEE_ID}}
Deleted At: {{DELETED_AT}}

This is an automated notification from Veza Lifecycle Management. Please take appropriate action to ensure security and compliance. ```
Relationship Management Templates **ADD\_RELATIONSHIP** * **Subject**: `New Relationship Added Notification: {{ENTITY_TYPE}} has an account with new relationship to a {{RELATIONSHIP_ENTITY_TYPE}}` * **Body**: ```html Hello,

{{ENTITY_NAME}} has a new relationship to {{RELATIONSHIP_ENTITY_NAME}}

Account Type: {{ENTITY_TYPE}}
Relationship Type: {{RELATIONSHIP_ENTITY_TYPE}}

``` **REMOVE\_RELATIONSHIP** * **Subject**: `Relationship Removed Notification: {{ENTITY_TYPE}} has an account whose relationship was remove from a {{RELATIONSHIP_ENTITY_TYPE}}` * **Body**: ```html Hello,

{{ENTITY_NAME}} has a relationship removed from {{RELATIONSHIP_ENTITY_NAME}}

Account Type: {{ENTITY_TYPE}}
Relationship Type: {{RELATIONSHIP_ENTITY_TYPE}}

``` **REMOVE\_DIRECT\_ACCESS** * **Subject**: `Direct Access Removed Notification: {{ENTITY_TYPE}} had direct access removed from {{RELATIONSHIP_ENTITY_TYPE}}` * **Body**: ```html Hello,

{{ENTITY_NAME}} had direct access removed from {{RELATIONSHIP_ENTITY_NAME}}

Account Type: {{ENTITY_TYPE}}
Resource Type: {{RELATIONSHIP_ENTITY_TYPE}}

```
Email Management Templates **CREATE\_EMAIL** * **Subject**: `New Email Notification: {{ENTITY_TYPE}} has an account with new email` * **Body**: ```html Hello,

{{ENTITY_NAME}} has a new email address

Account Type: {{ENTITY_TYPE}}
Email: {{EMAIL}}

``` **WRITE\_BACK\_EMAIL** * **Subject**: `New Write Back Email Notification: {{ENTITY_TYPE}} has had an email sync to it` * **Body**: ```html Hello,

{{ENTITY_NAME}} has the newly created email synced back to it

Account Type: {{ENTITY_TYPE}}
Email: {{EMAIL}}

```
Password Management Templates **CHANGE\_PASSWORD** * **Subject**: `Password Change Notification: {{ENTITY_TYPE}} has an account with a new password` * **Body**: ```html Hello,

{{ENTITY_NAME}} has a password

Account Type: {{ENTITY_TYPE}}
Login Name: {{LOGIN_NAME}}
New Password: {{LOGIN_PASSWORD}}

``` **RESET\_PASSWORD** * **Subject**: `Reset Password Notification: {{ENTITY_TYPE}} has had their password reset` * **Body**: ```html Hello,

{{ENTITY_NAME}} has had their password reset

Account Type: {{ENTITY_TYPE}}
Login Name: {{LOGIN_NAME}}
Temporary Password: {{LOGIN_PASSWORD}}

```
Entitlement Management Templates **CREATE\_ENTITLEMENT** * **Subject**: `Create entitlement notification: an entry of {{ENTITY_TYPE}} is created` * **Body**: ```html Hello,

An entry of {{ENTITY_TYPE}} is created: {{ENTITY_NAME}}

``` **RENAME\_ENTITLEMENT** * **Subject**: `Rename entitlement notification: an entry of {{ENTITY_TYPE}} is renamed` * **Body**: ```html Hello,

An entry of {{ENTITY_TYPE}} is renamed with new name: {{ENTITY_NAME}}

``` **SYNC\_ENTITLEMENT** * **Subject**: `Sync entitlement notification: an entry of {{ENTITY_TYPE}} is renamed` * **Body**: ```html Hello,

An entry of {{ENTITY_TYPE}} has been re-synced with the target system: {{ENTITY_NAME}}

```
Access Request Templates **ACCESS\_REQUEST\_COMPLETE** * **Subject**: `Access Request {{ACCESS_REQUEST_TYPE}} for {{ACCESS_REQUEST_ENTITY_NAME}} has {{SUCCEED_OR_FAILED}}` * **Body**: ```html Hello,

{{ACCESS_REQUEST_ENTITY_NAME}} has been {{ACCESS_REQUEST_TYPE}} with: {{ACCESS_REQUEST_TARGET_NAME}}.

User Type: {{ACCESS_REQUEST_ENTITY_TYPE}}
Target Type: {{ACCESS_REQUEST_TARGET_TYPE}}

``` **ACCESS\_REQUEST\_CREATED** * **Subject**: `{{ACCESS_REQUEST_SOURCE_TYPE}} for {{ACCESS_REQUEST_ENTITY_NAME}} is {{ACCESS_REQUEST_STATE}}` * **Body**: ```html Hello,

The request is currently in {{ACCESS_REQUEST_STATE}} state.
For details: {{ACCESS_REQUEST_URL}}
``` **ACCESS\_REQUEST\_FAILED** * **Subject**: `{{ACCESS_REQUEST_SOURCE_TYPE}} for {{ACCESS_REQUEST_ENTITY_NAME}} is failed` * **Body**: ```html Hello,

The request is failed, with an error message: {{EVENT_ERROR_MESSAGE}}
For details: {{ACCESS_REQUEST_URL}}
``` **ACCESS\_REQUEST\_STATE\_CHANGED** * **Subject**: `{{ACCESS_REQUEST_SOURCE_TYPE}} for {{ACCESS_REQUEST_ENTITY_NAME}} is {{ACCESS_REQUEST_STATE}}` * **Body**: ```html Hello,

The request is currently in {{ACCESS_REQUEST_STATE}} state.
For details: {{ACCESS_REQUEST_URL}}
``` **ACCESS\_REQUEST\_APPROVER\_ASSIGNED** * **Subject**: `{{ACCESS_REQUEST_SOURCE_TYPE}} for {{ACCESS_REQUEST_ENTITY_NAME}} in {{ACCESS_REQUEST_STATE}} as new assigned approvers` * **Body**: ```html Hello,

The request currently in {{ACCESS_REQUEST_STATE}} state has new been assigned new approvers.
For details: {{ACCESS_REQUEST_URL}}
```
Error and Failure Templates **ACTION\_FAILED** * **Subject**: `Action Failed: {{ACTION_NAME}} for identity {{IDENTITY_NAME}}` * **Body**: ```html Hello,

Action has failed.

Identity: {{IDENTITY_NAME}}
Action Name: {{ACTION_NAME}}
Action Type: {{ACTION_TYPE}}
Workflow Name: {{WORKFLOW_NAME}}
Error Message: {{EVENT_ERROR_MESSAGE}}

``` **WORKFLOW\_TASK\_FAILED** * **Subject**: `Workflow Failed: {{WORKFLOW_NAME}} for identity {{IDENTITY_NAME}}` * **Body**: ```html Hello,

Workflow has failed.

Identity: {{IDENTITY_NAME}}
Workflow Name: {{WORKFLOW_NAME}}
Error Message: {{EVENT_ERROR_MESSAGE}}

``` **EXTRACTION\_EVENT\_FAILED** * **Subject**: `Lifecycle Management extraction processing failed for {{DATASOURCE_ID}}` * **Body**: ```html Hello,

Extraction processing has failed.

Datasource: {{DATASOURCE_ID}}
Error Message: {{EVENT_ERROR_MESSAGE}}

```
Access Review Templates **CREATE\_ACCESS\_REVIEW\_QUEUED** * **Subject**: `Create Access Review Queued Notification: for identity {{IDENTITY_NAME}}` * **Body**: ```html Hello,

An access review has been queued for {{IDENTITY_NAME}}

``` **CREATE\_ACCESS\_REVIEW** * **Subject**: `Create Access Review Notification: for identity {{IDENTITY_NAME}}` * **Body**: ```html Hello,

An access review has been created for {{IDENTITY_NAME}}

```
Safety and Custom Action Templates **SAFETY\_LIMIT\_REACHED** (every safety limit: Hard Limit or Predictive Safety Limit, policy or workflow level) * **Subject**: `Safety Limit Reached Notification: Policy {{POLICY_NAME}} has stopped processing identity changes` * **Body**: ```html Hello,

The safety limit for policy {{POLICY_NAME}} has been reached. No further identity changes were processed.
``` The default template is the same whichever limit was reached. The `SAFETY_LIMIT_REACHED` event message names the limit and, for a workflow-level limit, the workflow. See [When a safety limit is reached](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md#when-a-safety-limit-is-reached). **CUSTOM\_ACTION** * **Subject**: `New Custom Action Notification: {{ENTITY_TYPE}} has performed a custom action` * **Body**: ```html Hello,

{{ENTITY_NAME}} has performed a custom action

Account Type: {{ENTITY_TYPE}}
Message: {{EVENT_ERROR_MESSAGE}}

``` **INVALID\_IDENTITIES\_DETECTED** * **Subject**: `Invalid Identities Detected: Policy {{POLICY_NAME}}` * **Body**: ```html Hello,

Invalid identities were detected during policy execution.

Policy: {{POLICY_NAME}}
Extraction Event: {{EXTRACTION_EVENT_ID}}

Summary: {{EVENT_MESSAGE}}

Please review the validation filters and check the individual invalid identity events in the policy history for detailed information.

```
Non-Human Identity (NHI) Templates **ROTATE\_KEY** * **Subject**: `Key Rotation Notification: {{ENTITY_NAME}}` * **Body**: ```html Hello,

Key {{ENTITY_NAME}} has been rotated.

{{EVENT_MESSAGE}}

```
### Image Attachments From the Veza UI, you can add images directly through the "Add images" option. These will be automatically encoded and included in your template. {% hint style="info" %} **Image Requirements**: For API-based template management, small images under 64kb can be attached when configuring a template. The image must be base64-encoded and specified in the `attachments` field of the API request. {% endhint %} To use an attachment you have uploaded in a template, specify it by `attachment.name`, for example: ```html User email: {{email}} Department: {{department}} Okta email: {{OktaUser.email}} AD username: {{ActiveDirectoryUser.sAMAccountName}} ``` {% hint style="info" %} **When to Use Typed Format**: Use `{{EntityType.attribute}}` format when your workflow processes multiple entity types and you need to reference a specific entity's attributes. For example, if your workflow processes both `OktaUser` and `ActiveDirectoryUser`, use `{{OktaUser.email}}` to specifically reference the Okta user's email address. {% endhint %} #### Predefined placeholders Veza populates the following static placeholders. Not every placeholder is available in every notification. Availability depends on whether the template is attached to a policy event or to an action, and on whether the action succeeded. See [Placeholder availability by notification type](#placeholder-availability-by-notification-type).
Identity and Entity Information | **Placeholder** | **Description** | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `{{ENTITY_TYPE}}` | The type of the account the action created or changed (for example, "ActiveDirectoryUser" or "OktaUser"). Event notifications only | | `{{ENTITY_NAME}}` | The name of the account the action created or changed. Event notifications only | | `{{LOGIN_NAME}}` | The login/username for the account | | `{{LOGIN_PASSWORD}}` | The password (for password-related notifications) | | `{{EMAIL}}` | Email address associated with the identity |
Relationship Information | **Placeholder** | **Description** | | ------------------------------ | -------------------------- | | `{{RELATIONSHIP_ENTITY_TYPE}}` | Type of the related entity | | `{{RELATIONSHIP_ENTITY_NAME}}` | Name of the related entity |
Action and Job Information | **Placeholder** | **Description** | | ----------------------- | ----------------------------------------------------------------------------------------- | | `{{ACTION_NAME}}` | Name of the action being performed; serves as the stable unique identifier for the action | | `{{ACTION_TYPE}}` | Type of action | | `{{ACTION_JOB_ID}}` | Unique identifier for the action job | | `{{SUCCEED_OR_FAILED}}` | Status indicator ("succeeded" or "failed") | | `{{SENT_INVITE}}` | Whether an invite was sent (for guest accounts) |
Access Request Information | **Placeholder** | **Description** | | -------------------------------- | -------------------------------------- | | `{{ACCESS_REQUEST_TYPE}}` | Type of Access Request | | `{{ACCESS_REQUEST_ENTITY_NAME}}` | Name of the entity requesting access | | `{{ACCESS_REQUEST_ENTITY_TYPE}}` | Type of the requesting entity | | `{{ACCESS_REQUEST_TARGET_TYPE}}` | Type of the target resource | | `{{ACCESS_REQUEST_TARGET_NAME}}` | Name of the target resource | | `{{ACCESS_REQUEST_URL}}` | URL to view the Access Request details | | `{{ACCESS_REQUEST_STATE}}` | Current state of the Access Request | | `{{ACCESS_REQUEST_SOURCE_TYPE}}` | Source type of the Access Request |
Event and Error Information | **Placeholder** | **Description** | | ------------------------- | ----------------------------------------------------------------------- | | `{{EVENT_TYPE}}` | Type of lifecycle event | | `{{JOB_ID}}` | Job identifier | | `{{EVENT_ERROR_MESSAGE}}` | Error message for failed events | | `{{EVENT_IDENTITY_ID}}` | ID of the identity the workflow runs for | | `{{EVENT_IDENTITY_NAME}}` | Name of the identity the workflow runs for, from the source of identity |
Policy and Workflow Information | **Placeholder** | **Description** | | ------------------- | ----------------------------------------------------------------------------- | | `{{POLICY_NAME}}` | Name of the lifecycle policy | | `{{WORKFLOW_NAME}}` | Name of the workflow; serves as the stable unique identifier for the workflow | | `{{DATASOURCE_ID}}` | Datasource identifier |
#### Placeholder availability by notification type A custom template works with both policy event notifications (**Policy Settings** > **Notifications**) and action notifications (**Edit Action** > **Action Notification Settings**). Each type fills a different set of built-in placeholders, and a placeholder the type does not fill stays in the message as literal text. `{{EVENT_IDENTITY_NAME}}` is the identity the workflow runs for. `{{ENTITY_NAME}}` is the account the action created or changed. * **Action notifications**: `{{ACTION_NAME}}`, `{{ACTION_TYPE}}`, `{{SUCCEED_OR_FAILED}}`, `{{ACTION_JOB_ID}}`, `{{JOB_ID}}`, `{{WORKFLOW_NAME}}`, `{{POLICY_NAME}}`, `{{EVENT_IDENTITY_NAME}}`, and `{{EVENT_IDENTITY_ID}}`. * `{{ACTION_URL}}` is filled only when the action fails with a system error. Otherwise, it stays as literal text. * `{{ENTITY_NAME}}` and `{{ENTITY_TYPE}}` are not available. * `{{EVENT_ERROR_MESSAGE}}` is empty. To include the failure reason, use a policy event notification. * The action's [result placeholders](#additional-placeholders), such as `{{LOGIN}}` and `{{SOURCE_ENTITY_NAME}}`, stay as literal text. `{{ANY_CHANGES}}` and `{{ANY_CREATED}}` read `false`. * **Event notifications when the action failed**: `{{EVENT_TYPE}}`, `{{ENTITY_NAME}}`, `{{ENTITY_TYPE}}`, `{{RELATIONSHIP_ENTITY_NAME}}`, `{{RELATIONSHIP_ENTITY_TYPE}}`, `{{JOB_ID}}`, `{{EVENT_ERROR_MESSAGE}}`, `{{EVENT_IDENTITY_NAME}}`, `{{EVENT_IDENTITY_ID}}`, `{{WORKFLOW_NAME}}`, `{{POLICY_NAME}}`, `{{ACTION_NAME}}`, and `{{ACTION_TYPE}}`. `{{ENTITY_NAME}}` and `{{ENTITY_TYPE}}` are empty if the action failed before it identified the account. * **Event notifications when changes were made successfully**: only the placeholders specific to that event. For example, a successful Reset Password event fills `{{ENTITY_NAME}}`, `{{ENTITY_TYPE}}`, `{{LOGIN_NAME}}`, and `{{LOGIN_PASSWORD}}`. Attribute placeholders such as `{{email}}` and `{{OktaUser.email}}` follow separate rules. See [Placeholder Resolution and Entity Scope](#placeholder-resolution-and-entity-scope). #### Troubleshooting placeholders **Placeholder Not Being Replaced?** If a placeholder appears in your notification email instead of being replaced with a value, check the following: 1. **Verify exact casing**: Placeholders are case-sensitive * ✅ Correct: `{{ENTITY_TYPE}}` * ❌ Wrong: `{{entity_type}}`, `{{EntityType}}`, `{{Entity_Type}}` 2. **Check placeholder format**: Ensure proper syntax with double curly braces * ✅ Correct: `{{ENTITY_NAME}}` * ❌ Wrong: `{ENTITY_NAME}`, `{{ENTITY_NAME}`, `ENTITY_NAME` 3. **Verify attribute exists**: For dynamic attributes, confirm the attribute is provided by your integration * Use the typed format to specify the entity type: `{{OktaUser.email}}` * Check your integration documentation for available attribute names and their casing 4. **Check event context**: Some placeholders are only available for specific events * For example, `{{LOGIN_PASSWORD}}` is only available in policy notifications for identity creation, sync, and password events * `{{ACCESS_REQUEST_URL}}` is only available for Access Request events * `{{ENTITY_NAME}}` and `{{ENTITY_TYPE}}` are not available in action notifications, and `{{EVENT_ERROR_MESSAGE}}` is empty there. Use `{{EVENT_IDENTITY_NAME}}`, or attach the template to a policy event notification; see [Placeholder availability by notification type](#placeholder-availability-by-notification-type). **Best Practices:** * **Start with predefined placeholders**: Use the documented static placeholders (uppercase) whenever possible * **Test templates**: Send test notifications to verify placeholder replacement before deploying to production * **Document custom attributes**: Keep a reference of the attribute names and casing used by your integrations * **Use typed format for clarity**: When working with multiple entity types, use `{{EntityType.attribute}}` to avoid ambiguity ### Placeholder Resolution and Entity Scope Whether a placeholder resolves to a value, and which record that value comes from, depends on two things: the form of the placeholder and the configuration surface the template is attached to. A placeholder that resolves correctly on one surface can fall through unresolved on another. This section describes how resolution works so you can author templates that reference the intended record. #### What each placeholder form resolves against Veza resolves three placeholder forms differently: | Form | Example | Resolves against | | -------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Built-in (uppercase) | `{{ACTION_NAME}}` | Populated directly by the workflow runner. No entity lookup. See [Predefined placeholders](#predefined-placeholders). | | Bare attribute | `{{email}}` | Input entities: the source-of-identity records first, then the output entities of earlier actions in the same workflow run. | | Qualified attribute | `{{OktaUser.email}}` | Output (target) entities first, then source-of-identity entities. | For the qualified form, when an entity type is in both the output entities and the source of identity, the output (target) value is used. {% hint style="warning" %} A bare placeholder such as `{{email}}` uses the source-of-identity value when the source of identity has that attribute. It falls back to an earlier action's output entity only when the source of identity doesn't. To reference an attribute on the account the workflow created or updated in a target system, use the qualified `{{EntityType.attribute}}` form with the exact registered entity type. {% endhint %} #### Which configuration surface provides which attributes A notification template can be attached to three surfaces, and each receives a different set of attributes: | Surface | Source-of-identity attributes | Target (output entity) attributes | | ----------------------------------------------------------------------- | ----------------------------- | ------------------------------------------------------------------------------- | | Event-based notification (per policy event) | Available | Available when the event carries an action result that produced output entities | | Action notification settings (`on_success` / `on_failure` on an action) | Available | Available from that action's output entities | | Send Notification action (standalone workflow node) | Available | Available from earlier actions in the same workflow run | {% hint style="warning" %} An email or ServiceNow **Send Notification** action produces no output entities of its own, and its action-result placeholders aren't filled. A Webhook Send Notification that waits for a response can return output entities in that response; see [Webhook responses](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-notification.md#webhook-responses). A qualified `{{EntityType.attribute}}` still resolves when an earlier action in the same workflow run produced that entity, for example a Sync Identities action that ran before the Send Notification step. If no earlier action produced the entity, the placeholder doesn't resolve. {% endhint %} #### Which actions populate target attributes Target (output entity) attributes are only available downstream when the action that ran produces output entities: | Action | Populates output entities | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | Sync Identities | Yes. Target user attributes are available to subsequent actions and to its own notifications. | | Send REST Payload | Only when **Add response to output entities** is enabled on the action. | | Send Notification | Only a Webhook notification that waits for a response, from the entities the response returns. Email and ServiceNow notifications don't. | | Pause, Deprovision, and similar terminal actions | Generally none of their own. Output entities from an earlier action in the same workflow can still be in scope. | When in doubt, confirm the source of an attribute against the producing action rather than assuming it is available everywhere in the workflow. #### Finding the canonical entity type for OAA integrations The qualified form requires the exact entity type string that the integration registered, not a friendly label from the UI. For OAA integrations, that string has the form `OAA..`, and it includes any spaces in the provider's display name. For example, a Jira Cloud user's email attribute is referenced as: ``` {{OAA.Jira Cloud.User.email}} ``` The space inside `Jira Cloud` is required. Veza splits the entity type from the attribute on the final period, so spaces inside the provider name are preserved. If the provider display name contains a period, the qualified form cannot address it. To find the canonical entity type for an integration, inspect an entity of that type in the Veza catalog or query the entity type through the API. Use the registered type string exactly as shown, including capitalization and spaces. #### Template selection order For a given notification, Veza selects the template to render in this order: 1. The custom template selected in **Select Email Template** for that notification, if one is selected. 2. The template your organization set as the default for the notification's usage, if there is one. For a policy notification, the usage is the event, such as **Create Identity**. For the Send Notification action and Action Notification Settings, it is **Action Succeeded** or **Action Failed**. The Send Notification action uses **Action Succeeded**. 3. The built-in template for that event, or for that action type. A default template for **Action Succeeded** applies to every Send Notification email and every action success email that uses **Default template**, in every policy. The template is stored per outcome (success or failure). In the UI, one selection applies to every outcome you check. To use different templates for success and failure, set them through the API. #### Unresolved placeholders and unsupported syntax Veza replaces each `{{key}}` token with its value. Templates can also use Handlebars conditional blocks such as `{{#if}}` and `{{else}}`, which Veza evaluates against the [predefined placeholders](#predefined-placeholders) only. For example, the built-in Send Notification template uses `{{#if ACTION_URL}}` to show a link only when there is one. Attribute placeholders such as `{{email}}` and `{{OktaUser.email}}` can't be used in a block condition. Keep attribute placeholders out of templates that contain a Handlebars block: Veza evaluates the blocks before it fills attribute placeholders, so those placeholders might not be filled. If a notification arrives with literal `{{...}}` text in it, check the activity log for the unresolved-placeholder warning. It lists the exact tokens that did not resolve, which distinguishes a wrong entity type prefix from an attribute that was simply empty. #### Additional placeholders Beyond the [predefined placeholders](#predefined-placeholders) listed above, individual actions populate result-specific placeholders. Availability is context-dependent: each token is only set by the action or event that produces it, so a placeholder valid in one notification may be empty in another.
Action and result placeholders | Placeholder | Typical context | | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------- | | `{{EVENT_MESSAGE}}` | Event notifications | | `{{EXTRACTION_EVENT_ID}}` | Extraction events | | `{{ACTION_URL}}` | Action notifications | | `{{ANY_CHANGES}}`, `{{ANY_CREATED}}` | Workflow change flags | | `{{IDENTITY_CREATED}}`, `{{IDENTITY_SYNCED}}` | Create or sync identity results | | `{{GUEST_ACCOUNT_CREATED}}`, `{{GUEST_ACCOUNT_INVITE_SENT}}`, `{{GUEST_ACCOUNT_SYNCED}}` | Guest account results | | `{{ATTRIBUTES_NOT_SYNCED}}`, `{{FAILED_ATTRIBUTE_DUE_TO_CONFLICT}}` | Sync identity results | | `{{CREATED_RELATIONSHIPS_COUNT}}`, `{{REMOVED_RELATIONSHIPS_COUNT}}`, `{{FAILED_CREATE_RELATIONSHIPS_COUNT}}`, `{{FAILED_REMOVE_RELATIONSHIPS_COUNT}}` | Relationship management results | | `{{SOURCE_ENTITY_TYPE}}`, `{{SOURCE_ENTITY_ID}}`, `{{SOURCE_ENTITY_NAME}}` | Source-of-identity reference | | `{{DEPROVISION_SUCCESSFUL}}`, `{{DEPROVISION_TYPE}}`, `{{LOGGED_OUT_USER}}`, `{{REMOVED_ALL_LICENSES}}`, `{{REMOVED_ALL_PERSONAL_DEVICES}}` | Deprovision results | | `{{ENTITLEMENT_CREATED}}`, `{{ENTITLEMENT_RENAMED}}`, `{{ENTITLEMENT_SYNCED}}`, `{{MEMBERS_SYNCED_COUNT}}` | Entitlement management results | | `{{RESULT_TYPE}}`, `{{PASSWORD_RESET_SUCCESSFUL}}`, `{{LOGIN}}`, `{{DELETE_SUCCESSFUL}}` | Action outcome results | | `{{ROTATED_KEY_COUNT}}`, `{{FAILED_KEY_COUNT}}` | Key rotation results | | `{{FULL_NAME}}`, `{{EMPLOYEE_ID}}`, `{{DELETED_AT}}`, `{{IDENTITY_LINK}}` | Identity reference | | `{{SYNCED_ENTITY_LIST}}`, `{{SYNCED_ENTITY_COUNT}}` | Sync results | | `{{EMAIL_ADDRESS}}`, `{{MESSAGE}}` | General |
### Webhook Configuration Overview Webhook notifications are triggered upon execution of actions during the LCM Policy workflow process. Webhooks inform stakeholders or integrate with external systems of events that are processed within the workflow. Webhook notifications can be optionally configured as their own discrete action in a workflow or as an option when another action is executed. For example, a webhook is sent to the company's learning management system to initiate online onboarding training once each new hire's Active Directory account is provisioned, following a successful Sync Identity operation. #### Create a Webhook To create and manage a webhook, perform the following: 1. Go to **Policies** and select a policy. 2. Click **Policy Settings** in the policy header. 3. Select **Notifications** and click **Add Notification**. 4. Choose the **Webhook** notification type. 5. Choose an **event to trigger** notifications. See [Notifications](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md#notifications) for the event list. 6. Under **Send a notification if:**, choose **Changes were made successfully**, **The action failed**, or both. 7. Select the Veza Action in **Select Veza Action**. A Veza Action is an integration with functionality for sending data to external systems, enabling downstream processes around Veza alerts, and access to reviewer actions. Use a Veza Action to configure generic webhooks or enable email notifications. See Veza Actions [Webhooks](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications/destinations/webhooks.md) on how to create and deploy a webhook. 8. To customize the Webhook setting, perform the following: * In the **Webhook URL** field, enter the endpoint configured to receive the webhook payload. * In the **Webhook Auth Header** field, enter the Auth Header if the webhook listener requires authentication. When configured, webhook requests include an Authorization header containing the credentials specified in the **Webhook Auth Header** field. This allows the receiving endpoint to authenticate the request using Bearer tokens, API keys, or other authentication schemes. 9. Click **Save**. --- # 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/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.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.