Policies define the rules and actions for managing identities throughout their lifecycle. Workflows within policies execute based on specific conditions, automating processes such as onboarding, role changes, and offboarding.

In this section

Key concepts

• Policies: Top-level configuration for a source of identity that defines which workflows apply

• Workflows: Sequences of actions that execute when specific conditions are met

• Trigger Conditions: Boolean expressions using SCIM filter syntax (e.g., is_active eq true)

• Actions: Tasks like creating accounts, assigning groups, or sending notifications

Related topics

• Access Profiles - Define birthright entitlements for provisioning actions

• Attribute Transformers - Format attributes when provisioning accounts

Overview

Lifecycle Management policies define the workflows that are triggered when a user is added or other events are detected at a specific source of identity. Workflows contained in a policy describe conditional sequences of actions that can be structured based on the specific joiner, mover, leaver (JML) scenarios that you want to automate. This might include hiring a new employee, terminating an existing employee, transferring an existing employee to another department, or other actions triggered by changes in status.

A policy can contain one or more workflows that run under different conditions. For example, one workflow might be applied when employees enter an "Active" state (for Joiner/Rehire scenarios), and another when an employee becomes "Inactive" (for Leaver scenarios). A workflow could also be triggered when an employee's hire date falls within a certain threshold, such as being less than 4 days away, or when it is related to any other employee property within the source of identity.

For most enterprise deployments, Veza recommends:

• One policy for each source of identity integrated with Lifecycle Management

• Two workflows within each policy:

  • One for active users to cover Joiner and/or Mover scenarios (including Re-hire)

Add a Lifecycle Management Policy

To create a policy for a source of identity:

1. Go to Policies.

2. Click Create Policy.

3. Enter a policy name and description.

Simulation Dry Run on Policy

The Dry Run allows you to simulate and preview how a Policy would process an identity, without making actual changes to target systems. This testing tool helps you validate workflow conditions, preview potential changes, and understand what actions would be triggered for specific identities.

How Dry Run Works

The Dry Run evaluates workflow logic but does not interact with target integrations. Verify integration health to ensure target systems are accessible before running actual policies. Dry Run takes a policy and an identity to simulate:

• The workflows triggered

• All actions that would run

• What Access Profiles would be assigned

• Any potential changes to entities and attributes

You can test how policies would respond to identity attribute changes for different scenarios during a Dry Run simulation without impacting the actual identity attribute values.

Starting a Dry Run

You can initiate a Dry Run in two ways:

From a Lifecycle Management Policy

When editing a policy, open the Dry Run tool to preview changes for any identity:

1. Go to Policies.

2. Click a policy to view its details.

3. Click Dry Run Policy at the top right.

4. Choose the identity and policy to test workflows.

From Identity Details

You can start a Dry Run when viewing details for any account on the Identities page:

1. Go to Identities.

2. Search for an identity and click to view its details.

3. Expand the Actions menu at the top right and click Policy Dry Run.

Dry Run Notes:

Result: 0 Changes

When a dry run returns "0 changes", it means:

• The selected identity does not meet any of the trigger conditions defined in your policy's workflows

• No actions would be executed for this identity when the policy runs

• This is not an error - it simply means the identity doesn't qualify for any of the configured workflows

Limitations

Dry Run has several important limitations:

• Dry Run evaluates whether workflow conditions are met, not whether actions would succeed

• It does not check whether integrations are functioning properly and whether target systems are accessible

• It does not validate that changes could be successfully applied

Best Practices

Use Dry Run to validate that policies and their workflows are working as intended before enabling them in a live environment.

1. Test with Representative Identities: Select identities that represent different scenarios (new hires, role changes, terminations) to validate all workflows in your policy.

2. Simulate Different Scenarios: Modify identity attributes during Dry Run to test trigger conditions such as:

   • Department changes

• Handling long names or names with special characters

• Department and location change at once

• Same-day rehire after termination

Workflow execution behavior

Understanding how workflows execute helps with troubleshooting and policy design.

Execution order

When identity source data changes, Veza processes it in this order:

1. Extraction completes: Data is pulled from the identity source.

2. Workflow triggers evaluate: Veza begins evaluating trigger conditions within approximately 1 second of extraction completing. Actual evaluation time scales with the number of managed identities. Policies with thousands of identities can take several minutes to process. For policies with multiple identity sources, evaluation waits until all configured sources have completed extraction.

3. Conditions evaluate: Conditions within a workflow evaluate sequentially, in the order defined.

Trigger behavior

"First time only" triggers

Most workflows (except sync workflows) are configured to trigger "only when trigger condition is first met." This means:

• The workflow triggers the first time an identity matches the condition.

• If the condition clears (identity no longer matches) and then matches again, the workflow triggers again as if it were the first time.

• This behavior handles rehire scenarios where a previously terminated employee returns.

Sync workflows

Sync workflows track specific properties for changes. When adding new properties that require syncing:

• Update the tracked property list in the workflow configuration.

• Update sync-related common transformers to include the new attributes.

For more information on workflow triggers, see .

SCIM condition limitations

Trigger conditions use SCIM filter syntax. When comparing values, only the variable on the right side of the comparison can be transformed. The left side must be an attribute reference without transformation. See for syntax details.

Policy Version

Policies can be version-controlled, allowing for a method to refine and test changes in your automation workflows. You can create draft versions to test changes and validate updates before deployment while maintaining a history of previous configurations. Each policy can have only one active version and one draft version at a time, with automatic archival of retired versions.

Policy State vs Workflow Versioning State

Policies have a current state that is based on their workflow operations.

The Policy state includes:

• Initial - Initially created before the first workflow version is published

• Running - Actively processing with one or more workflows

• Paused - Temporarily disabled

• Pending - Waiting for activation

Note: In the Policies page, click on the Action overflow icon (three dots) to Start the policy in the Initial state, and Pause or Unpause at the Running state.

The Workflow Version state includes:

• Draft - In draft mode for editing and modification

• Published - Functional and active

• Retired - No longer active or usable

Policy Draft Mode

The Policy Draft Mode is a state where a policy is saved but not yet active. In Policy Draft Mode, you can create, edit, and test policy configurations (such as workflows, actions, or mappings) without affecting real users, identities, or access profiles. Once you are satisfied, you can publish the policy, which moves it from the work-in-progress state to an operational state.

To enable the Policy Draft Mode, perform the following:

1. On the Lifecycle Management Dashboard page, click Settings in the top menu.

2. The Lifecycle Management Settings page appears. Click Policy Settings.

3. Switch ON the Enable Policy Draft Mode button.

Test Policy Workflows using Draft Versioning

You can test and refine your policy workflows to ensure that it is working as expected through a series of draft versions with Dry Run simulations. Once the workflow’s result is satisfactory, publishing the version will change the policy status to ‘active’.

Perform the following steps to test your policy workflow:

1. Create and save a new policy.

2. Create a new workflow and Save.

3. After creating a new workflow, click Publish.

4. By publishing your workflow, it is ready for activation by going to the

Published Policy

A published policy is activated and deployed with the following characteristics:

• Enforces the defined rules in your environments, including:

  • Creating, modifying, or removing user access.

  • Synchronizing identity attributes.

Migrating policies between environments

For organizations using multiple Veza tenants (such as sandbox and production), policies can be migrated between environments using migration scripts provided by Veza support.

When to use migration scripts

Use the migration script approach for:

• Large policies with many workflows and complex transformers

• Repeated migrations between the same environments (sandbox → production)

• Policies where manual reconstruction would be time-consuming

For simple policies or one-time migrations, manual reconstruction may be faster than setting up the migration toolkit.

Environment setup (one-time)

1. In both sandbox and production tenants, log in as an Integration Manager or Administrator and create API keys (Integrations > API Key).

2. Store each key in a password manager or secrets vault.

3. Set environment variables for the migration script:

Migration procedure

1. In the target tenant, create a new draft version of the policy and note the version number.

2. If any of the following changed since the last migration, update the lookup table CSV (provided by support) with new IDs:

   • Access Profiles

Extraction scheduling and policy control

Extraction schedules

Extraction schedules for identity sources are configured via the Veza API. To modify extraction frequency or timing, contact for assistance with API configuration.

Workflow parallelism

The maximum number of concurrent workflows is configured at the tenant level via API. This setting controls how many workflow jobs can run simultaneously across all policies. Contact to adjust concurrency limits for your deployment.

Policy pause behavior

Disabling a policy pauses any running workflows. Re-enabling the policy does not resume paused workflows—they restart on the next extraction cycle.

Enabling and Monitoring Lifecycle Management Policies

Use the Policies page for an overview of initial, running, and paused policies. New policies are created in the "Initial" state, enabling a review period before activating the policy. Active ("Running") policies will apply the next time the data source is extracted.

To manage policies on the main Policies overview:

1. Go to Lifecycle Management > Policies

2. Find the policy you want to manage

   • Search for a specific policy by name

Add Workflows to Policies

Policies contain one or more workflows. Typically, workflows correspond to Active and Inactive user states, but not always. More specifically, workflows define a sequence of actions to run when a condition is met, based on events and identity changes captured at the source of identity. These workflows apply to scenarios such as new employee hiring, internal employee mobility changes (e.g., promotions, transfers, new managers), or employee departures.

Workflows comprise a tree-like sequence of conditions designed to meet the specific requirements of your joiner, mover, and leaver processes. For example, you may want to grant specific entitlements to users with specific roles, locations, or groups.

Example Workflows

The following diagrams illustrate typical joiner and leaver workflow implementations, showing how identity changes in your HR system trigger coordinated provisioning and de-provisioning actions across multiple target applications.

Joiner Workflow

When a new employee is created in Workday, Veza automatically provisions accounts and assigns appropriate access across connected systems based on the employee's role and attributes.

Leaver Workflow

When an employee's status changes to inactive or terminated in Workday, Veza automatically de-provisions accounts and removes access to protect your organization's security posture.

Workflows and Trigger Conditions

Trigger Conditions refer to rules or filters that initiate (or delay) provisioning and deprovisioning workflows based on certain events, criteria within identity data sources, or lifecycle workflows. Trigger conditions use SCIM filter syntax to evaluate whether an identity matches specific criteria.

See for SCIM filter syntax and available operators, or for a comparison with transformer syntax.

• Trigger conditions are often tied to HR events, such as employee hiring (joiner), role changes (mover), or termination (leaver). For instance, provisioning flows can be triggered when an employee is hired or deprovisioned when terminated.

• Trigger Conditions can be time-based, such as "create the Active Directory account 15 days prior to a new employee's start date".

• Advanced implementations also support relationship-based triggers (e.g., launching workflows when a worker is added to a specific department). Note: Trigger conditions can also encompass

Create a Workflow

To add a workflow, perform the following:

1. Select a policy.

2. Click Create Workflow.

3. In Details, enter the workflow name and description.

4. In the

• Not set

• Low

• Normal

• Medium

The levels dictate the order/priority in which the workflows are run. The higher-priority setting will be processed first. A fairness algorithm is built in to prevent lower-priority workflow tasks from being starved.

1. In the New Workflow pane, click trigger attribute. The Edit Workflow pane appears.

2. In the Triggering Condition (Condition String) field, select a conditional string from the dropdown menu to create a logical syntax that automatically starts the workflow. Once a condition has been set, another conditional string can follow, or an action can be taken.

3. In the Options section, select one of the following:

Note: All workflow errors must be resolved before it can be saved.

Clone or Delete a Workflow

Once an LCM Policy workflow is saved, the clone and delete options appear alongside the workflow name:

• Click on the copy icon to clone the workflow.

• Click on the trash bin icon to delete the workflow.

Common workflow patterns

Webhook notifications after Sync Identity

For ITSM integrations that need to receive all attributes after a Sync Identity action completes:

1. Place the webhook action under a condition that follows the Sync Identity action in the workflow tree.

2. Add a pause action before the webhook if needed to allow time for attribute propagation.

3. Use clear naming conventions for conditions (for example, "FTE New Hire AD Notification") to indicate their purpose.

Create a Transformer

A transformer is a rule or function that takes incoming identity or attribute data and modifies it into the format or value that the target system requires.

They’re used when the data source system and target system represent or store information differently. For example, transformers can:

• Converting a username from “First.Last” format into all lowercase.

• Mapping a department value like “HR” in the source to “Human_Resources” in the target.

• Adding a prefix or suffix to attributes (e.g., appending a domain name to create an email).

Transformers act as data processors inside a policy, ensuring that the right values are sent when provisioning, updating, or deprovisioning identities and entitlements.

To add a transformer, perform the following:

1. Select a policy.

2. Click Transformers.

3. Click Add Transformer.

4. In the New Transformer

See for available transformation functions.

Create a Lookup Table

Lookup tables are CSV files with columns that map values from a source of identity to destination values. Each row represents a mapping entry. The first row must contain the column headers.

This example is a location mapping table, which is a typical format for a Lookup Table:

Once a Lookup Table has been uploaded, it can be processed with the Lookup Transformers. The Lookup transformers convert identity attributes from a source system into appropriate values for target systems based on CSV reference tables. This is particularly useful when mapping values between systems that use different naming conventions, codes, or formats for the same conceptual data.

Use Lookup Table Transformers to:

• Map source attribute values to different values in target systems

• Standardized reference data that must be consistent across applications

• Extract different pieces of information from a single attribute value

• Have complex mapping requirements that built-in transformers cannot support

See for detailed information.

To add a Lookup Table, perform the following:

1. Select a policy.

2. Click Lookup Table.

3. Click Add Lookup Table.

4. In the New Lookup Table

Create Properties

Properties are the attributes that describe identities, accounts, and entitlements. They serve as the data points a policy can use to determine when and how to take action. Properties can come from:

• Built-in properties – default attributes that LCM provides out-of-the-box (for example: username, email, status, created_at).

• Custom properties – attributes defined by your organization to capture unique metadata (for example: cost_center, employee_type, manager_id).

Use Properties to:

• Properties are referenced in policy conditions (e.g., disable account if status = inactive).

• Help with transformers and lookup tables, allowing you to map or reformat values.

• Used in identity overrides when syncing accounts from different providers.

To add Properties, perform the following:

1. Select a policy.

2. Click Properties.

3. The Mover Properties appear. Click Edit Properties.

Create Password Complexity Rules

Password Complexity Rules in a policy ensure that generated passwords adhere to standardized criteria according to defined password policies across automated provisioning workflows. You can define reusable password complexity rules to enforce requirements for password length, mandatory character types (uppercase letters, lowercase letters, numbers, and special characters), and restricted characters when generating random passwords. These rules are available for selection in Sync Identities, Deprovision Identity, and Reset Password actions when working with integrations that support complex password requirements.

To add Password Complexity Rules, perform the following:

1. Select a policy.

2. Click Password Complexity Rules.

3. Click Create Password Complexity Rule.

4. In the

Create Transformer Functions

Custom Transformer Functions allow you to programmatically modify or enrich identity attributes as they are synced from identity sources to target systems. These transformations ensure that data formats align across systems and support more dynamic provisioning logic. Such transformers can:

• Convert dates into required formats or perform date-based calculations (e.g., adding days to a hire date).

• Normalize or transform string values (e.g., case conversion, trimming, substrings).

• Apply conditional logic via functions directly within provisioning rules.

To add Transformer Functions, perform the following:

1. Select a policy.

2. Click Transformer Functions.

3. Click Create Custom Transformer Function.

4. In the

Policy Settings

The Policy Settings page provides information about a specific policy and allows for additional configuration, including:

• Modify the primary identity source

• Define an additional data source to the primary identity source

• Configure email notifications or a webhook for action-related events

• Enable continuous synchronization to ensure identities are up-to-date

Details

The Details view shows the Policy Name and Description fields. These fields are editable for name change or description refinement, if required.

Primary Identity Source

The Primary Identity Source pane displays the integration name of the data source. The Integration field displays all available data sources, where you can add or remove, if required.

A Primary Identity Source is the authoritative system that serves as the source of truth for user identities (e.g., HR system, Active Directory, identity provider like Okta/Entra ID). Typically, one type of source of identity is associated with one integration.

The role of the Primary Identity Source includes:

• Acts as the authoritative record for user information (emails, roles, statuses).

• Lifecycle rules such as provisioning, updates, or deprovisioning are typically triggered based on changes detected in this data source.

• Ensures consistency and accuracy across target systems where access is granted or revoked.

Additional Identity Sources

As an option, the Additional Identity Sources pane is typically used to add a different type of integration from the Primary Identity Source, which requires that the additional data source be already configured into Lifecycle Management. You can also correlate primary attributes and additional attributes to be associated with the data source. The added data source will sync for authentication, user updates, or provisioning.

To add an Additional Identity Source, perform the following:

1. Click Add Source.

2. In the Select Identity Source field, select a data source. Note: If you enable the 'These types are not related' option, then you cannot correlate any attributes.

3. In the Correlating Attributes pane, select a Primary Attribute from the dropdown menu.

Notifications

When events occur during the execution of a policy’s workflow, notifications can be triggered upon execution of actions in workflows as a means to inform stakeholders or integrate with external systems. These notifications can be optionally configured as their own discrete action in a workflow or as an option when another action is executed. Lifecycle Management supports email- and webhook-based notifications.

For example, an organization might configure its Active Employee policy to send an email to the manager of each new hire after the employee's email address is provisioned. Additionally, a webhook will be sent to the company's learning management system to initiate online onboarding training once each new hire's Okta account is provisioned, following a successful Sync Identity operation.

Use the Notifications to add and manage notifications:

1. In the Notifications pane, click Add Notification.

2. Choose the notification type (Email or Webhook).

3. Choose the event to trigger notifications:

See for customizing email notifications.

Advanced Settings

Identity Syncing Option

Identity Syncing at the policy level defines how identities from the authoritative source are synchronized into the target system, including provisioning user accounts or updating existing identities.

The Identity Syncing option controls the behavior of the Sync Identities Actions in a policy workflow, which has Continuous Sync functionality enabled.

Select either:

• Sync on changes only - to skip identity syncing when no data source changes are detected

• Always sync - to sync, no matter if changes are detected or not

Safety Limits

Safety Limits prevent unintended mass changes to identities by enforcing configurable thresholds. Two independent mechanisms are available and can be used together for layered protection:

Hard Limit

The Hard Limit (formerly "Safety Limit") is a reactive mechanism that stops processing during execution once the configured number of identity changes has been reached. When the limit is triggered, no further identity changes are processed for the current policy run.

To configure a Hard Limit:

1. Enable the Hard Limit toggle.

2. Set the Maximum Number of Affected Identities to define the threshold.

Predictive Safety Limit

The Predictive Safety Limit is a proactive mechanism that blocks all changes before execution begins if the system predicts the number of workflow runs will exceed configured thresholds. This prevents unintended mass processing of identities when upstream attribute changes in a Source of Identity would trigger unnecessary Joiner, Mover, or Leaver workflows.

To configure a Predictive Safety Limit:

1. Enable the Predictive Safety Limit toggle.

2. Set the Maximum Number of Workflow Runs to define the threshold.

Workflow-Level Limits

Safety limits can be configured at both the policy level and individual workflow level for granular control. When configured at the workflow level, each workflow enforces its own thresholds independently, enabling different limits for Joiner, Mover, and Leaver workflows within the same policy.

Blocked Tasks

When a Predictive Safety Limit triggers, no changes are processed. A warning appears on the Blocked Tasks page with options to:

• Review what would have changed

• Run the blocked tasks (manually approve execution)

• Abandon the blocked tasks (discard without executing)

Processing of future extractions is paused until the administrator acknowledges the warning and resumes processing. New activity log event types PREDICTED_SAFETY_LIMIT_EXCEEDED and WORKFLOW_PREDICTED_SAFETY_LIMIT_EXCEEDED are recorded when predictive limits trigger.

Overview

REST Auth Credentials provide centralized, reusable authentication configurations for Send REST Request actions in Lifecycle Management workflows. Instead of configuring authentication directly in each action, you can create named credential sets that multiple actions can reference.

Benefits:

• Reuse: Share authentication across multiple Send REST Request actions

• Security: Sensitive fields (passwords, tokens, secrets) are encrypted at rest

• Centralized management: Update credentials in one place; all referencing actions use the latest configuration

• Audit: Track credential usage and creation history

Supported Authentication Types

Configuring REST Auth Credentials

Using the Veza UI

1. Navigate to Lifecycle Management > Settings

2. Select the Rest Credentials tab

3. Click Create to add a new credential

4. Enter a Name for the credential

5. Select the Auth Type and fill in the required fields (see )

6. Optionally set a default URL and HTTP Method (actions can override these values)

7. Click Save

Using the REST API

REST Auth Credentials are managed via the Lifecycle Management API:

Create a credential:

curl -X POST "https://{VEZA_URL}/api/private/lifecycle_management/rest_auth_credentials" \
  -H "Authorization: Bearer {API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "value": {
      "name": "My API Credential",
      "auth_type": "BEARER",
      "bearer_settings": {
        "token": "eyJhbGciOiJIUzI1NiIs..."
      },
      "url": "https://api.example.com/v1",
      "method": "POST"
    }
  }'

List credentials:

curl "https://{VEZA_URL}/api/private/lifecycle_management/rest_auth_credentials" \
  -H "Authorization: Bearer {API_KEY}"

Get a single credential:

curl "https://{VEZA_URL}/api/private/lifecycle_management/rest_auth_credentials/{CREDENTIAL_ID}" \
  -H "Authorization: Bearer {API_KEY}"

Update a credential:

curl -X PATCH "https://{VEZA_URL}/api/private/lifecycle_management/rest_auth_credentials/{CREDENTIAL_ID}" \
  -H "Authorization: Bearer {API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "value": {
      "id": "{CREDENTIAL_ID}",
      "name": "Updated Credential Name",
      "bearer_settings": {
        "token": "new-token-value"
      }
    }
  }'

Delete a credential:

curl -X DELETE "https://{VEZA_URL}/api/private/lifecycle_management/rest_auth_credentials/{CREDENTIAL_ID}" \
  -H "Authorization: Bearer {API_KEY}"

Auth Type Configuration

Header

Provides a custom authorization header value. Use this for API keys or non-standard token formats.

The value is sent as the Authorization header on each request.

Basic

HTTP Basic authentication with username and password.

Veza constructs the Authorization: Basic {base64(username:password)} header automatically.

Bearer

Bearer token authentication.

Veza constructs the Authorization: Bearer {token} header automatically.

Login to Bearer

Two-step authentication: perform a login request, then extract a bearer token from the response. Use this for APIs that require an initial authentication step before issuing a session token.

How it works:

1. Veza sends a POST request to login_url with login_payload_json as the body

2. The JSON response is parsed using bearer_token_attribute to extract the token

3. The extracted token is used as a Bearer token for the actual REST request

Example:

If the login API returns:

{
  "value": {
    "token": "eyJhbGciOiJIUzI1NiIs...",
    "expires_in": 3600
  }
}

Set bearer_token_attribute to value.token to extract the token.

OAuth2

OAuth 2.0 client credentials flow.

Veza performs the client credentials flow to obtain an access token, then uses it as a Bearer token for the REST request.

Choosing an authentication method:

• FORM (default): Sends client_id and client_secret as form-encoded parameters in the POST body alongside grant_type=client_credentials. Use this when the token endpoint expects credentials in the request body.

• BASIC: Sends credentials in the Authorization: Basic base64(client_id:client_secret) header, with only grant_type=client_credentials in the POST body. Use this when the token endpoint requires HTTP Basic authentication.

Check your target API's OAuth2 documentation to determine which method it supports. Both conform to RFC 6749 §2.3.1. When in doubt, try FORM first as it is the default and more widely supported.

None

No authentication header is added to the request. Use this when the target API is public or when authentication is handled through other means (e.g., network-level security, pre-shared keys in URL parameters).

Using Credentials in Actions

When configuring a Send REST Request action in a Lifecycle Management policy:

1. In the action configuration, select a credential from the REST Auth Credentials dropdown

2. The credential provides the authentication header and optional default URL/method

3. The action's Webhook URL and HTTP Method settings override the credential defaults when specified

Permissions

See Also

• Send REST Request Action: Action configuration and payload options

• Custom Application with Send REST Payload: Route requests through Insight Points for on-premises targets

• Transformers: Attribute transformation syntax for dynamic URLs and payloads

Overview

Lifecycle Management supports three integration pathways for custom applications. This document covers configuring the OAA Write Framework pathway with Insight Point routing for Send REST Payload actions.

When using the Send REST Request action in Lifecycle Management workflows, requests execute from the Veza control plane by default. For target APIs that are on-premises or behind a firewall, you can configure a Custom Provider (OAA integration) to route requests through an Insight Point agent instead.

This configuration enables:

• On-premises API access: Call internal APIs that aren't accessible from the public internet

• Network isolation: Route requests through your own infrastructure for security compliance

• Hybrid deployments: Mix cloud-based and on-premises targets in the same workflow

When to Use This Configuration

You DO NOT need this configuration if:

• Your target API is publicly accessible

• You're calling cloud services (SaaS APIs, webhooks)

• Your Send REST Payload actions work without selecting a data source

You NEED this configuration if:

• Your target API is on-premises or in a private network

• The API is only accessible from specific network locations

• You need requests to originate from an Insight Point agent

How It Works

Without Data Source (Default):

With Data Source (Insight Point Routing):

When a Custom Provider is configured with external_lifecycle_management_type: SEND_REST_PAYLOAD:

1. The provider's data source appears in the Send REST Payload action's Data Source dropdown

2. Selecting it routes the HTTP request through the associated Insight Point

3. The Insight Point agent executes the request from within your network

Configuration

This setting is configured via the Veza REST API. It is not currently available in the Veza UI. The provider configuration only sets up Insight Point routing—the actual request URL, HTTP method, payload, and authentication are configured per-action in the policy editor.

Create Custom Provider with Send REST Payload Support

curl -X POST "https://{VEZA_URL}/api/v1/providers/custom" \
  -H "Authorization: Bearer {API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "On-Prem HR System",
    "custom_template": "application",
    "provisioning": true,
    "external_lifecycle_management_type": "SEND_REST_PAYLOAD",
    "data_plane_id": "{INSIGHT_POINT_ID}"
  }'

Update Existing Custom Provider

curl -X PATCH "https://{VEZA_URL}/api/v1/providers/custom/{PROVIDER_ID}" \
  -H "Authorization: Bearer {API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "provider": {
      "id": "{PROVIDER_ID}",
      "provisioning": true,
      "external_lifecycle_management_type": "SEND_REST_PAYLOAD"
    },
    "update_mask": {
      "paths": ["provisioning", "external_lifecycle_management_type"]
    }
  }'

Required Fields

Validation Rules

• Provisioning required: provisioning must be true when setting external_lifecycle_management_type

• No internal app name: Cannot be used with internal_app_name (these are mutually exclusive)

• No configuration_json: Unlike , Send REST Payload does not use configuration_json. Including it in the request will cause a validation error. Authentication is configured per-action using the setting or .

• Cannot change type while in use: external_lifecycle_management_type cannot be changed while the provider is referenced by Lifecycle Management policies. Remove the provider from all policies before changing this field.

Using in Lifecycle Management Policies

Once configured, the Custom Provider's data source will appear in the Send REST Payload action configuration:

1. In the policy editor, add a Send REST Payload action

2. In the Data Source field, select your configured Custom Provider

3. Configure the URL, method, headers, and payload as needed

4. The request will route through the associated Insight Point

Combining with REST Auth Credentials

You can use REST Auth Credentials together with Insight Point routing:

• REST Auth Credentials: Handle authentication (OAuth2, Bearer tokens, etc.)

• Data Source selection: Routes the request through an Insight Point

When a Data Source is selected, both the token acquisition request and the subsequent REST request execute through the Insight Point. This means Login to Bearer and OAuth2 credential types work correctly against token endpoints that are not publicly accessible—the entire authentication flow remains within your private network.

Troubleshooting

Data Source Dropdown is Empty

If no data sources appear in the Send REST Payload action's Data Source dropdown:

1. No providers configured: Verify you have at least one Custom Provider with external_lifecycle_management_type: SEND_REST_PAYLOAD

2. Provisioning not enabled: Check that provisioning: true is set on the provider

3. No data source created: Push an OAA payload to create a data source for the provider

Validation Error: "external_lifecycle_management_type requires provisioning to be true"

Include provisioning: true in your API request along with the external_lifecycle_management_type field.

Validation Error: "data_plane_id: Cannot be empty"

The data_plane_id is required when creating a provider with external_lifecycle_management_type: SEND_REST_PAYLOAD. Ensure you have a deployed Insight Point and include its ID in your create request.

Validation Error: "cannot change external_lifecycle_management_type while provider is in use by LCM"

The provider is referenced by one or more Lifecycle Management policies. Remove the provider from all policies before changing its external_lifecycle_management_type.

Request Fails from Insight Point

If requests fail when routed through an Insight Point:

1. Network connectivity: Verify the Insight Point can reach the target API

2. Firewall rules: Ensure outbound HTTPS is allowed from the Insight Point to the target

3. DNS resolution: Confirm the target hostname resolves from the Insight Point's network

4. TLS certificates: If the target API uses an internal or self-signed CA certificate, the Insight Point will fail with tls: failed to verify certificate: x509: certificate signed by unknown authority. You must add the CA certificate to the Insight Point's trust store:

   • OVA deployment: See

   • Install script deployment: See

See Also

• Lifecycle Management Integrations: Overview of integration pathways (Native, SCIM, OAA Write Framework)

• Send REST Request Action: Action configuration, variable substitution, and response handling

• REST Auth Credentials: Centralized authentication management for Send REST Request actions

• : Alternative LCM option using SCIM endpoints (requires configuration_json)

• : Agent deployment, connectivity requirements, and high availability

• : Custom integration development

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 Veza using the notifications API, and a reference for event types, default templates, and supported placeholders.

Managing notification templates

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 and action notification settings. 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 both Send Notification actions and action notification settings (on_success/on_failure)

• Standard placeholder support: Supports all the same placeholders as event-based templates

To create a custom email template:

1. Navigate to Lifecycle Management > Settings > Notifications

2. Click Create Template

3. Select For Custom Email (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 when configuring the Send Notification action, or in Action Notification Settings:

• Send Notification action: Choose from the "Select Email Template" dropdown when configuring the action

• Action Notification Settings: Select the template for on_success or on_failure email notifications on any action

When you select "Default template" in these dropdowns, the system uses the event-based template appropriate for the event. When you select a custom template, that template is used regardless of the specific event being processed.

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><body>
<br>
<br> Here is the notification that lifecycle job has failed. <br>
Error message: {{EVENT_ERROR_MESSAGE}}<br>
<br>
For reference:
<br> job_id: {{JOB_ID}}<br>
<br> identity_id: {{EVENT_IDENTITY_ID}}
<br> identity_name: {{EVENT_IDENTITY_NAME}}
<br> entity_type: {{ENTITY_TYPE}}
<br> entity_name: {{ENTITY_NAME}}
</body></html>

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

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.

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.

To use an attachment you have uploaded in a template, specify it by attachment.name, for example:

<img src="cid:<name_of_attachment>"

To embed high-resolution images in your templates, you should serve the content from a public URL, and use HTML to link and style it.

Placeholders

Use placeholders to include dynamic information in templates, such as entity names, action types, timestamps, and other event metadata. Placeholders are automatically replaced with actual values when notifications are sent.

How placeholders work

Veza notification templates support two types of placeholders:

1. Static Placeholders (Predefined)

These are uppercase constants documented in the tables below (e.g., {{ENTITY_TYPE}}, {{ENTITY_NAME}}). They are replaced first during template processing and work with all notification templates.

Example:

Hello,
New account created for {{ENTITY_NAME}} with type {{ENTITY_TYPE}}.

2. Dynamic Attribute Placeholders

You can also reference any attribute from the entities being processed using two formats:

• Untyped format: {{attribute_name}} - References an attribute by name alone

• Typed format: {{EntityType.attribute_name}} - References an attribute from a specific entity type

The attribute name must exactly match the casing used by your integration. For example:

• If your integration provides an attribute named email, use {{email}}

• If it provides Email, use {{Email}}

• If it provides employee_id, use {{employee_id}}

Examples:

<!-- Untyped - uses attribute from any entity -->
User email: {{email}}
Department: {{department}}

<!-- Typed - uses attribute from specific entity type -->
Okta email: {{OktaUser.email}}
AD username: {{ActiveDirectoryUser.sAMAccountName}}

Predefined placeholders

The following static placeholders are available in all notification templates:

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 for password-related events

   • {{ACCESS_REQUEST_URL}} is only available for Access Request events

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

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 Edit Policy.

3. Click Policy Settings.

4. Scroll down to Notifications and click Add Notification.

5. Choose the Webhook notification type.

6. Choose an event to trigger notifications:

   • Create Identity

   • Sync Identity

   • Add Relationship
7. Choose the status to trigger notifications (when an event is Successful, or On Failure).

8. Select an Existing 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 on how to create and deploy a webhook.

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

10. Click Save.

This guide explains how to create Access Reviews from Lifecycle Management workflows and troubleshoot common issues.

Lifecycle Management (LCM) policies can trigger Access Reviews automatically using the CREATE_ACCESS_REVIEW action. When a workflow runs and conditions match, Veza queues and creates an access review campaign based on the configured certification plan.

Overview

Use LCM-triggered access reviews to:

• Automatically certify access when employees change roles (movers)

• Review permissions before offboarding (leavers)

• Validate access grants after onboarding (joiners)

• Enforce periodic re-certification based on identity attribute changes

The sections below cover configuration options and troubleshooting for reviews created by LCM workflows.

Troubleshoot missing reviews

Common scenarios:

• All results filtered: Veza created the review but then deleted it because all rows already appeared in recent in-progress reviews

• Entity type mismatch: The policy identity type does not match the access review query, and no identity graph relationship exists to resolve it. Veza displays this error: "No matching node type found for identity type {type}"

• Missing workflow configuration: The Access Review workflow is not configured or not linked to the policy

LCM-triggered reviews always run when a workflow executes, but Veza deletes the review if it has no results after filtering.

Veza compares each row against the last five in-progress reviews (by default) for the same workflow. The system excludes rows that appeared in any of those reviews. If all rows are excluded, Veza deletes the review rather than completing it with zero results. Veza does not send notifications for deleted reviews.

To verify a review was created and deleted:

• Check Veza Events for the review creation and deletion

• Review Lifecycle Management event logs for the workflow execution

• Note: Deleted LCM-triggered reviews do not appear in the Reviews list (unlike manually-created empty reviews, which do appear)

Understand unchanged result filtering

LCM and Rule-triggered Access Reviews automatically exclude unchanged results. Veza enables this setting by default, and you cannot disable it for these review types.

When Veza creates a review, it compares each row against the last five in-progress reviews for the same workflow (sorted by start time, newest first). The system excludes rows that appeared in any of those reviews, leaving only new or changed access to review.

This behavior:

• Applies automatically to all LCM_TRIGGERED and RULE_TRIGGERED reviews

• Compares against the last five in-progress reviews by default (configurable by Veza support)

• Cannot be changed through the UI or API

• Does not apply to manually-created or scheduled reviews

If filtering excludes all rows, Veza deletes the review rather than completing it with zero results. Veza does not send notifications for deleted reviews, but the deletion appears in Veza Events.

Resolve entity type mismatches

LCM-triggered access reviews require the policy identity entity type to match the entity type defined in the access review query. Veza resolves this match in the following order:

1. Direct match in source node types: The policy identity type matches directly

2. Direct match in destination node types: The policy identity type matches the destination

3. Linked nodes through the identity graph: Veza follows graph relationships to find a connection (for example, WorkdayWorker → ActiveDirectoryUser)

If none of these resolve, the review creation fails with the error: "No matching node type found for identity type {type}".

Example: If your policy tracks WorkdayWorker identities and your review expects ActiveDirectoryUser entities, Veza still creates the review successfully if there is a defined relationship (for example, WorkdayWorker → ActiveDirectoryUser) in the identity graph. If no such mapping exists, the review creation fails.

Fix missing enriched identity columns

Access Reviews can include enriched columns that display additional identity attributes (such as department or manager from an HRIS system). However, Veza skips enrichment when the identity mapping is ambiguous.

When Veza skips enrichment:

If a single account or entity maps to multiple identity nodes in the graph (for example, one Active Directory account maps to two different WorkdayWorker records), Veza intentionally skips enrichment rather than arbitrarily choosing one.

Result:

• Veza still creates the review successfully

• Enriched columns appear but remain empty for affected rows

• Veza logs a trace-level warning: "Skipping enriching nodes due to finding multiple linked nodes"

Resolution:

Review your identity mappings to ensure each account maps to a single identity. Ambiguous mappings often indicate data quality issues in source systems (such as duplicate employee records).

Customize review names

When creating access reviews through LCM workflows, you can configure a custom review name using attribute transformers. This is useful when a workflow creates multiple reviews and you need to differentiate them.

Common use case (Movers): When employees change roles, a single workflow run can trigger multiple access reviews. Custom names help reviewers identify which review corresponds to which change.

Transformer syntax:

Use curly braces to reference identity attributes:

• Review for {name} → "Review for John Smith"

• {department} Access Review - {name} → "Engineering Access Review - John Smith"

• {job_title} Certification → "Senior Engineer Certification"

See Attribute Transformers for the complete transformer syntax reference.

Dry Run verification:

Custom review names appear in Dry Run results, allowing you to verify the name format before the workflow runs in production. This helps catch transformer syntax errors or missing attributes early.

Related topics

• Access Reviews: Complete guide to configuring and managing access certification campaigns

• Access Reviews configuration: Creating and configuring certification plans

• CREATE_ACCESS_REVIEW action: Configuring the workflow action settings

• : Customizing review names with dynamic attributes

When creating workflows in Lifecycle Management policies to create, sync, or deprovision identities, you will use attribute transformers to specify how user attributes for target accounts should be structured.

An attribute transformer is the complete configuration for mapping a source attribute to a destination attribute. It consists of:

The target attributes to create or update are typically mapped and, optionally, transformed from user metadata in the source of identity, such as an identity provider, HR system, or CSV upload. Attributes can be synchronized once or kept continuously in sync as changes occur throughout the user's employment lifecycle.

For example, attribute mapping and transformation can be used across Joiner, Mover, and Leaver scenarios:

• Joiner: Set new Azure AD User Principal Name to {source username}@your-email-domain.com. This is an example of mapping multiple attributes and performing a transformation. More specifically, you use the attribute transformer to generate an email address for new joiners. Use the source username (user_principal_name) from the source of identity (Azure AD UPN) for the first part (user attribute), while your-email-domain.com is used for the last part (target attribute).

• Mover: Always update a user’s “Manager” and “Department” attributes in Okta to match the user’s manager and department in Workday, a source of identity, whenever a department change or other employee mobility event occurs. This is an example of attribute mapping with continuous synchronization.

• Leaver: Move a user’s Active Directory account to an Organizational Unit (OU) reserved for terminated accounts.

When synchronizing a user’s attributes, Veza may apply many transformations to convert the source attribute values into a more suitable format intended for the target application as a user account attribute.

For example, a transformer might remove the domain from an email address, replace special characters, or convert a string with uppercase letters to lowercase letters.

See Attribute Synchronization for detailed information.

Key Terminology

Adding transformers

Common transformers define one or more rules to apply when synchronizing the attributes of a target identity. Use them at the Policy level where you want to create or update attributes using the same conventions across multiple sync or deprovision actions. When you need to configure a one-time individual action in a workflow, such as a specific attribute, then you use the transformer at the Action level.

At the Policy level, you configure a transformer with basic details, including how to source the value of each attribute:

1. Assign a name and description to the transformer, and specify the data source to which it applies.

2. Entity Type: Choose the target entity type in the destination system.

3. Click Add Attribute. The Destination Attribute dropdown will list available attributes for the chosen entity type.

   • Destination Attribute: Choose the attribute that Veza will create or update for the target entity.

   • Formatter: Choose how the destination attribute should be formatted. Specify the value, a {source_attribute}, or apply .

   • Then Apply: Chains transformation functions together using the pipe (|) character. Each function runs in sequence, with the output of one becoming the input of the next.

   See for more examples.

   • Continuous Sync: Enabling this option ensures that the attribute is always synced, while applying any defined transformations. By default, attributes will not be synced if the target identity already exists.

After creating a common transformer, you can select it when editing a workflow action. You can edit or delete common transformers on the Edit Policy > Common Transformers tab. Remember that "Sync Identity" and "De-Provision Identity" actions can have action-level transformers override common transformers. If the same destination attribute is defined in both, the action-level transformer will take precedence.

Best practices

When to use common transformers

Create common transformers when the same transformation logic appears in two or more places within the policy. Common transformers reduce duplication and ensure consistent formatting across actions.

When to use transformer functions

Create transformer functions when the same transformation applies to multiple properties. Functions let you reuse logic without duplicating configuration.

Formatter syntax

The Formatter field in a transformer specifies how to construct the attribute value. It can be set to a specific value, synchronized with a source attribute, transformed using a function, or a combination of these.

Simple Value Setting

To create a destination attribute with a fixed value, enter the desired value when configuring the formatter. For setting the creator attribute:

For activating a re-hired employee:

Empty Values

To clear an attribute value, leave the formatter field empty. The behavior at the destination depends on system type:

• SQL-based destinations (Oracle, MySQL, MSSQL): an empty formatter sends NULL to the database column.

• SCIM destinations: an empty formatter sends an empty string to the provider.

For deactivating a user or clearing a manager reference:

Attribute references

Target attributes can be updated based on attributes belonging to the source of identity. To reference the value of a source entity attribute in your formatter, use the format {<source_attribute_name>}.

Examples:

Alias Definitions

When to use aliases

By default, when you reference an attribute such as {department} in a formatter, the system searches through your configured identity sources in order (primary first, then secondary sources). This works well for simple policies with a single source of identity.

Aliases become useful when:

• Multiple integrations share the same entity type (e.g., two Active Directory instances, or when your source of identity and sync target use the same entity type)

• A policy involves multiple integrations that have attributes with the same name

• You need to explicitly control which system's attribute value is used

• You want to compare values between source and target systems while defining LCM Workflow Conditions

• You need to detect movers based on changes in a specific system

Example: HR System to Directory Sync

A policy syncs identities from an HR system (Workday) to a directory (Active Directory). Both have a department attribute. Without aliases, {department} resolves from whichever system appears first in the search order. With configured aliases hr and directory (which become $hr and $directory), you can explicitly reference {$hr.department} to ensure you're using the authoritative HR value.

Aliases can be used in:

• Attribute formatters

• Workflow trigger conditions

• Action conditions

• Mover property definitions

• Test formatters (for validation before deployment)

Configuring aliases

Aliases provide shorthand references to specific integrations and entity types, making transformers and conditions more readable in complex policies.

To configure aliases, open a Lifecycle Management policy, click Edit, and navigate to the Alias Definitions tab. Each alias requires:

• Alias Name: Must start with $ followed by at least one lowercase letter, number, or underscore. Additional $ characters can appear after the first character. The $ prefix is added automatically if omitted. Valid examples: $workday, $hr_system, $ad$corp. Invalid examples: $, $AD (uppercase), $$double (multiple leading $).

• Integration: The data source containing the entity type.

• Entity Type: The entity type to reference (e.g., WorkdayWorker, OktaUser).

Input and output resolution

Aliases can resolve attributes from two contexts:

• Input: Values from the source system before any sync action runs (the authoritative data)

• Output: Values currently in the target system (what's already provisioned)

By default, the system checks output first, then falls back to input. Use suffixes to explicitly control resolution:

Comparison operators

Use these operators in IF conditions to compare attribute values:

Combine conditions with and, or, or negate with not.

Examples

In attribute formatters:

{$workday.first_name | LOWER}.{$workday.last_name | LOWER}@company.com

In LCM Workflow Conditions (comparing source and target values):

IF $workday$in.department ne $ad$out.department
  {$workday$in.department}
ELSE
  {$ad$out.department}

Multiple integrations with the same entity type:

For organizations with multiple Active Directory domains (e.g., corporate employees and contractors), you can create distinct aliases to control which AD integration is used:

• Configure alias corp_ad → Integration: AD_Corporate, Entity Type: ActiveDirectoryUser

• Configure alias contractor_ad → Integration: AD_Contractors, Entity Type: ActiveDirectoryUser

Then explicitly reference the correct domain in your formatters:

{$corp_ad.department}

This ensures you're using the department attribute from the corporate AD integration rather than the contractor AD integration, even though both use the same ActiveDirectoryUser entity type.

Transformation functions

Based on the user metadata available from your source of identity (SOI), you may need to convert a full email address to a valid username, standardize a date, or generate a unique identifier for users provisioned by Veza. Suppose an attribute value needs to be altered to be compatible with the target system. In that case, you can transform the value of a source attribute or apply a range of other functions to generate the target value.

Formatter expressions use the following syntax: {<source_attribute_name> | <FUNCTION_NAME>,<param1>,<param2>}

For example:

Transformation function categories

Refer to the Transformer Reference page for complete documentation of all supported functions, parameters, and usage examples. The reference includes:

Then Apply {#then-apply}

You can pipeline multiple transformation functions together, separated by a vertical bar (|). Each will apply in sequence, allowing for complex attribute formatters that use the output of one function as the input of another.

Example Then Apply

• {name | UPPER}

  • If name = Smith, the result is SMITH.

• {first_name | SUB_STRING,0,1 | LOWER}.{last_name | LOWER}

  • If first_name = John and last_name = Smith, the result is j.smith.

• {email | REMOVE_DOMAIN}

  • If email = [email protected], the result is john.smith.

• {email | REPLACE_ALL, " ", "."}

  • If email = john [email protected], the result is [email protected].

• {location | LOOKUP locationTable, location_code, city}

  • If location = IL001, the result is Chicago (using a lookup table named locationTable).

• {start_date | DATE_FORMAT, "01/02/2006" | UPPER}

  • If start_date = 2023-03-15, the result is 03/15/2023 (DATE_FORMAT doesn't typically need UPPER, but shows pipeline capability).

• {hire_date | DATE_FORMAT, "Jan 2, 2006" | REPLACE_ALL, " ", "_"}

  • If hire_date = 2023-03-15, the result is Mar_15,_2023.

• {office_code | TRIM_CHARS_LEFT, ".0" | TRIM_CHARS_RIGHT, ".USCA"}

  • If office_code = 000.8675309.USCA, the result is 8675309.

• {username | REMOVE_CHARS, ".-_" | TRIM | UPPER}

  • If username = "–john.doe_–", the result is JOHNDOE.

• {employee_id | REMOVE_CHARS, "#" | TRIM_CHARS, "0" | LEFT_PAD, 6, "0"}

  • If employee_id = "##001234##", the result is 001234.

• {department | REMOVE_WHITESPACE | LOWER | REPLACE_ALL, "&", "and"}

  • If department = "Sales & Marketing", the result is salesandmarketing.

• TEST{| RANDOM_INTEGER, 1000, 9999}

  • Generates test IDs like TEST4827, TEST8391 (see for details).

Testing Transformers Inline

Before deploying transformers in production policies, you can validate formatter expressions directly in the Veza UI. This allows you to verify that your transformation logic produces the expected output without affecting live data.

Using the Test Interface

When adding or editing a transformer in a policy, look for the Test Formatter button next to the transformer field. Clicking it opens a test dialog:

1. Enter your transformer expression in the Attribute Transformer field

2. Click the Test Formatter button to open the test dialog

3. The dialog shows input fields for each attribute referenced in your expression (e.g., {first_name}, {email})

4. Enter sample values for each attribute

5. Click Test Formatter in the dialog to evaluate the expression

6. View the result to verify the transformation produces expected output

7. Click Save to close the dialog, or Cancel to discard changes

The test dialog is available wherever transformers are configured, including:

• Action synced attributes

• Unique identifiers

• Common transformers

• Date formatters

Testing Examples

Testing Then Apply

For complex pipelines, test incrementally:

1. Test the first function alone to verify it handles the input correctly

2. Add each subsequent pipe and verify intermediate results

3. Validate the complete pipeline produces the final expected value

This step-by-step approach helps isolate issues when a transformation doesn't produce the expected output.

When to Use Inline Testing vs. Dry Run

Use inline testing during transformer development, then validate the complete policy with a dry run before deploying to production.

Common Transformers

As part of implementing Lifecycle Management (LCM) processes with Veza, you should create sets of common transformers to define how values such as username, login, or ID are sourced for each LCM Policy. These transformers can then be reused across all identity sync and deprovision policy workflows.

For example, defining a common synced attribute to describe how to format Azure AD account names {username}@evergreentrucks.com enables reuse across multiple workflow actions. You can also define synced attributes at the action level when they are used only once within a policy, such as setting the primary group DN and OU of de-provisioned identities to a group reserved for terminated accounts.

Common Transformer Examples:

$target Attribute Transformer Function

The $target attribute transformer function is used when a value consists of one or more attributes that require an operation(s), making it too complex to transform, but it needs to be reused.

For example, an email address consists of [email protected]. However, you must use the format [email protected]. By using the $target function, you reuse only one attribute, username, while not changing the other two attributes (firstname_lastname).

Example:

Destination Attribute

username

Formatter

`{firstname}{lastname}`

Formatter

`{$target.username}@sample.com`

Using Transformed Attributes as Lookup Keys

You can reference an attribute set by an earlier transformer as the lookup key in a subsequent transformer. This enables multi-stage transformation pipelines where one transformer computes a normalized value, and a later transformer uses that value for table lookups or other operations.

Example: Compute a padded employee ID in one transformer, then use it to look up a cost center in a later transformer:

Transformer 1 — set padded_id:

{employee_id | LEFT_PAD, 8, "0"}

Transformer 2 — use padded_id as the lookup key:

{$target.padded_id | LOOKUP costCenterTable, padded_id, cost_center}

The $target.padded_id reference resolves to the value set by Transformer 1, and passes it as the key into the LOOKUP function.

Custom Attribute Transformer Function

The Custom Attribute Transformer function allows you to define a custom transformer that acts as an alias for applying one or more transformer functions.

For example, you can define a custom function named $CLEAN, which is used as {first_name | $CLEAN}. This function can consist of a series of transformer functions such as | ASCII | LOWER | REMOVE_CHAR |.

To define a custom attribute transformer, use the following guidelines:

Policy Version Definitions

• Custom functions must be defined as part of the policy version.

• These definitions are structured similarly to hard-coded definitions and are returned in the same format, allowing the Veza UI to handle them without modification.

• The API for updating and retrieving a policy version must also support these custom function definitions.

Custom Attribute Transformer Limitations

The following custom definitions are not supported:

• Transformer functions with included transformer parameters

• Nested transformer functions

• Transformer functions with parameters

Appending Multi-Value Attribute (Active Directory only)

As part of the Identity Sync action, you can append values to multi-value Active Directory attributes without replacing existing values. This ensures that existing attribute values are preserved when adding new ones.

Supported Multi-Value Attributes:

Active Directory supports appending for the following multi-value attributes:

• organizationalStatus, departmentNumber, employeeType

• servicePrincipalName, proxyAddresses

• member, memberOf, roleOccupant

• url, wWWHomePage

• otherTelephone, otherMobile, otherIpPhone, otherFacsimileTelephoneNumber, otherHomePhone, otherPager, otherMailbox

• And additional multi-value attributes including: objectClass, postalAddress, postOfficeBox, seeAlso, userCertificate, userSMIMECertificate, userPKCS12, securityIdentifierHistory, altSecurityIdentities, businessCategory

Syntax:

Use the >> prefix before the array to append values:

>>[value1, value2, value3]

Appending syntax supports two array formats:

• With quotes (JSON format): >>[``"Active", "Permanent"]

• Without quotes (simple format): >>[Active, Permanent]

When you use this syntax:

1. New values are added to the end of the existing attribute values

2. Duplicate values are automatically removed

3. The order of existing values is preserved

4. New values appear after existing values in the order specified

For example, ff an Active Directory user has:

organizationalStatus: ["Active", "Employee"]

And you apply the transformer:

>>[Employee, Contractor, Temporary]

The resulting value is:

organizationalStatus: ["Active", "Employee", "Contractor", "Temporary"]

Note that "Employee" was already present and not duplicated.

Setting vs. Appending:

• To Replace existing values: Use [value1, value2] (without >>)

• To Append to existing values: Use >>[value1, value2] (with >>)

Additional Notes:

• The append prefix (>>) only works for multi-value attributes. It is ignored for single-value attributes

• If the attribute has no existing values, the values are simply set (no difference from non-append behavior)

• Both the appending syntax and the standard array syntax support arrays with or without quotes around values

Overview

Veza can automate user provisioning and de-provisioning for any application that uses the Open Authorization API (OAA) for data gathering and authorization modeling, and exposes SCIM-compliant endpoints for user and group management.

This enables organizations to:

• Use your application's existing SCIM endpoints for automated provisioning operations

• Model complex authorization structures using OAA's flexible templates (applications, resources, permissions, custom properties) for Access Graph visibility, Access Reviews, and other Veza features.

• Gather authorization metadata using a variety of methods (custom connectors, APIs, manual JSON payloads, CSV files)

Supported Actions

See Supported Actions for details on each action type.

Enabling Lifecycle Management for Custom Applications (OAA SCIM)

Prerequisites

1. Administrative access in Veza to configure the integration

2. An existing OAA custom application integration in Veza with at least one successful extraction

3. Your custom application must expose SCIM 2.0-compliant endpoints; see Required SCIM 2.0 Endpoints below

4. SCIM connection details for the custom application (URL, authentication credentials)

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for your custom OAA application integration

3. Check the box to Enable usage for Lifecycle Management

To verify the configuration:

1. Open Lifecycle Management > Integrations

2. Search for the integration and click to view details

3. In the Properties panel, verify Lifecycle Management Enabled is active

Lifecycle Management and Access Requests with Open Authorization API

There are several potential ways to integrate a custom application for automated lifecycle management and access requests:

1. External SCIM for Open Authorization API: You may build your OAA integration using the custom application template and leverage dedicated SCIM endpoints for user and group management. This is useful when you need full control over how authorization metadata is represented in the Veza Access Graph:

   • Your application supports SCIM, and you want to model a wider range of authorization entities and metadata (e.g., credentials, resources) than the Veza SCIM integration supports.

   • You already have a custom OAA integration and want to add provisioning capabilities using SCIM.

2. Full SCIM Connector: Use the built-in SCIM connector for both basic data gathering and lifecycle management. This will provide visibility into supported SCIM entities and relationships with schedulable extractions, but not for the full range of entities and metadata that might be modeled using the Application Template such as roles and resources.

3. Custom REST API Actions: Actions in Veza may directly call any external API and capture the response in audit trails. This can enable Lifecycle Management and Access Requests for any target system, provided it has appropriate endpoints for managing users and access controls.

This document describes how to enable External SCIM for an Open Authorization API integration, and supported actions.

How It Works

Data Gathering (OAA):

You will need to design and build a custom integration to publish information about the application to the Veza Access Graph:

• The payload can include local users, groups, permissions, resources, and complex authorization relationships

• Data can be gathered from any source: APIs, databases, configuration files, etc.

See the rest of the Open Authorization API documentation for examples and best practices when designing and deploying custom integrations.

Lifecycle Management (SCIM):

You can enable the SCIM connection at the custom provider level:

• Setting provisioning: true and external_lifecycle_management_type: SCIM for the custom provider enables Veza to use your application's SCIM endpoints for provisioning

• Provide SCIM connection information and credentials (configuration_json)

• Veza maps lifecycle actions to SCIM operations (POST /Users, PATCH /Users/{id}, etc.)

Important: When configuring a custom application for SCIM integration, the OAA payload structure (Application template) and SCIM configuration serve different purposes:

• The OAA Payload (push_application() or API push) defines local users, groups, permissions, and resources used for visibility and authorization modeling in Veza, and can be updated independently.

• The SCIM Configuration (configuration_json) for the custom provider defines how to connect to SCIM endpoints (including authentication, URL, and endpoint paths), and is used only for lifecycle management and access request operations.

Both must be consistent (describe and contain the same users and groups), but are configured separately.

Required SCIM 2.0 Endpoints

Your application must expose SCIM 2.0 compliant endpoints with the following operations:

User Management:

• GET /Users - List and filter users

• GET /Users?filter=userName eq "{username}" - Query users by userName

• POST /Users - Create new users

• GET /Users/{id} - Retrieve specific user by ID

• PATCH /Users/{id} - Update user attributes

• DELETE /Users/{id} - Delete user (required if using Delete Identity action)

Group Management:

• GET /Groups - List groups

• GET /Groups/{id} - Retrieve specific group by ID

• POST /Groups - Create new groups

• PATCH /Groups/{id} - Update group membership

• DELETE /Groups/{id} - Delete group (optional)

Note: If the Users and Groups APIs are not at the standard /Users and /Groups paths, you can specify alternate endpoint paths in the configuration.

Authentication

Your SCIM API must support one of the following authentication methods:

• Bearer Token: API token passed in Authorization: Bearer {token} header

• Basic HTTP Authentication: Username and password passed in Authorization: Basic {credentials} header

The authentication credentials must have both read and write permissions to the SCIM endpoints.

Optional: Extension Attributes

To synchronize custom attributes beyond the standard SCIM user schema:

• Expose a GET /Schemas endpoint that returns SCIM schema definitions

• Enable schema fetching in your configuration (see Configuration section)

Configuration

External SCIM for Lifecycle Management is configured via the Veza REST API.

Create Custom Provider with External SCIM

Create a Custom Provider that uses external SCIM endpoints specifically for lifecycle management:

curl -X POST "https://{VEZA_URL}/api/v1/providers/custom" \
  -H "authorization: Bearer {API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "MyCustomApp",
    "custom_template": "application",
    "provisioning": true,
    "external_lifecycle_management_type": "SCIM",
    "configuration_json": "{\"scim_url\":\"https://api.myapp.com/scim/v2\",\"scim_token\":\"your-bearer-token\"}"
  }'

Required Fields

Configuration JSON Parameters

The configuration_json field contains SCIM endpoint connection details used only for provisioning operations. It does not affect your OAA payload structure.