Attribute synchronization ensures that identity attributes in target systems remain up to date with the corresponding attributes in the source of truth. Veza Lifecycle Management provides configuration at two levels to control how and when attributes are synchronized.

Action Level

At the action level, there are two distinct options to govern provisioning and user update processes:

• Create accounts - Turn this setting on for the action to create user accounts that don't exist in the target system. When it is off, users that don't already exist are skipped.

• Update existing accounts - Turn this setting on for the action to update existing active user accounts with attribute changes from the source of truth. When it is off, existing active users are not modified, and changes apply only when a user is created or reactivated.

Attribute Level

At the attribute level, the Apply On setting has two explicit choices that define how and when attribute values are applied to user accounts:

• Create only - The attribute value is set only when creating new user accounts

• Create and update - The attribute value is set for new accounts and updated for existing accounts when changes are detected

Both levels must be properly configured for an attribute to be continuously synchronized. For example, to keep an employee's department updated:

1. Turn on Update existing accounts on the Provision Account action

2. Set Apply On to Create and update for the department attribute

How Veza applies an update to an existing account depends on the target integration. For Active Directory, see .

Create and update (continuously sync attributes that change during employment):

• Given Name, Surname

• Department

• Title

• Manager

• Cost Center

Create only (preserve stable identifiers):

• Active Directory sAMAccountName

• Email Addresses (for Email Write-Back action)

A write-back Provision Account action that maps email to update existing records in a Human Resources Information System (HRIS) is the exception: set Apply On to Create and update for that attribute. See .

This configuration ensures that dynamic attributes remain up to date while preserving stable identifiers.

The Send Notification action is a workflow step. When the workflow reaches it, it sends an email, calls a webhook, or opens a ServiceNow ticket. Because it runs inside the workflow, it can run under a condition and after other actions, and its email can use attributes that earlier actions produced.

This page also covers Action Notification Settings, which add a notification to another action. Lifecycle Management offers three ways to send a notification:

Choose by what the message is for:

• Policy notification: watch for a kind of event across the policy, such as every failed action or every time a safety limit is reached. It is the only way to notify on events that happen outside a workflow run, such as Extraction Processing Failed. See .

• Action Notification Settings: report the outcome of one action, typically its failure.

• Send Notification action: send a message as a step in the workflow, for example after the identity's accounts are created, only when a condition is met, as a ServiceNow ticket, or to a webhook that reports a result back to the workflow.

All three use the same recipient fields and the same .

Example Use Cases:

• Alert IT staff when provisioning is complete

• Notify the identity's manager of access changes (see )

• Create a service desk ticket for any manual steps

• Send standardized notifications using custom templates across workflows

When configuring email notifications (either as a Send Notification action or in Action Notification Settings), you can choose which template to use:

• Default template: Uses your organization's default template for Action Succeeded or Action Failed notifications if one is set, and otherwise the action's built-in template. A default template for Action Succeeded applies to every Send Notification email and every action success email that uses Default template, in every policy.

• Custom template: Uses a reusable custom email template you've created, allowing consistent messaging across multiple workflows

Custom templates support placeholders for dynamic content such as identity names and workflow names. Which placeholders are filled depends on the notification type; see . See for placeholder reference and template management.

Email notifications have four recipient fields. The same fields appear on the Send Notification action, in Action Notification Settings, and in policy notifications:

• Select Recipient (Veza Action): an email Veza Action, which sends to the one address it stores.

• Recipients: email addresses you enter.

• Recipients From User's Attributes: identity attributes that hold email addresses.

• Email Formatters: expressions that build an address from the identity's attributes.

If you select an email Veza Action, Veza sends only to the Veza Action's address. Selecting one clears the other three fields and makes them unavailable. Without a Veza Action, Veza sends one email addressed to everyone the other three fields resolve to.

Policy notifications for the Action Failed, Workflow Task Failed, and Extraction Processing Failed events are sent without the identity's attributes. On those events, Recipients From User's Attributes and Email Formatters resolve no addresses, so use Recipients or a Veza Action.

Templates have no placeholder for the identity's manager, and a template can't look up another entity. To send a notification to the manager, add the manager as a recipient in one of two ways:

• The identity has an attribute with the manager's email address: select that attribute in Recipients From User's Attributes, for example manager_email.

• The identity has only a manager ID: add an that uses to look up the manager's email address. For example, {manager_id | FROM_ENTITY_ATTRIBUTE, "OktaUser", "employee_id", "email"} finds the Okta user whose employee_id matches the identity's manager_id and sends to that user's email.

To notify both the identity and the manager, also select the identity's own email attribute, such as email, in Recipients From User's Attributes. Both people receive the same email.

Email Formatters build a recipient address from the attributes of the identity being processed, for cases where no attribute holds the full address. They're available on Send Notification actions, in Action Notification Settings, and in policy-level notifications. On Send Notification actions, Available in Veza v2026.9.7 and later.

To add a formatter, select Add Formatter under Email Formatters, then enter an expression in the Formatter field. Expressions use the same syntax as : place attribute names in curly braces and add transformation functions with a pipe. Use Then Apply to run more functions on the result. For example:

• {email | LOWER} sends to the identity's email address in lowercase.

• {first_name}.{last_name}@company.com builds an address from the identity's name.

Formatters read attributes from the policy's source of identity, including secondary sources. You can add more than one formatter to reach different recipients for the same identity.

Addresses from formatters are added to the addresses in Recipients and Recipients From User's Attributes. A formatter that can't be evaluated or doesn't produce a valid email address is skipped, and the notification goes to the remaining recipients. If no recipients remain, no email is sent. When a notification uses an email Veza Action, the recipient fields, including Email Formatters, are unavailable.

When a Send Notification action uses the Webhook notification type, the payload Veza sends includes a returnPostUrl field. The receiving system can use this callback URL to report a result back to Veza after it finishes processing, for example after it opens a ticket, completes an approval, or provisions an account in another system.

The action's wait-for-response duration, in seconds, controls whether Veza waits for that result:

• 0: Veza doesn't wait. The action completes when the webhook is sent.

• Greater than 0: Veza waits up to that many seconds and uses the returned result as the action's result. If no result arrives in time, the action fails with a timeout error.

To return a result, the receiving system sends a POST to the returnPostUrl, authenticated with a Veza API token for a user with the Administrator, Operator, or OAA Push . The URL points to the endpoint for the job. Useful fields in the request body include:

• info_messages: status strings such as ticket numbers, approval decisions, or notes, recorded against the job.

• output_entities: entities the downstream system created or changed.

• error_message, any_changes, and any_created: outcome details for the job.

The returned result is stored on the job. Review the job on the Integration Jobs tab of the page, or retrieve it with the API.

Overview

This guide explains how to configure identity override attributes in Lifecycle Management to address scenarios where user attributes at the source of identity are incorrect, slow to update, or temporarily need adjustment for policy execution.

Identity override attributes allow Lifecycle Management administrators to override the value of any user attribute set at the source of identity. These overrides take precedence over actual values during Lifecycle Management workflows.

Problem scenarios for attribute overrides

Identity override attributes address operational challenges where the source of identity doesn't immediately reflect ground truth:

• Incorrect or slow-to-update attributes:

  • Employee termination: An employee has been terminated and needs immediate deprovisioning, but the termination status is not yet reflected at the source of identity

  • Role changes: An employee has immediately changed roles and needs new birthright access, but the role change and the new manager haven't been updated in the source system

  • Contract extensions: A contractor's end date has been extended, but the extension isn't reflected yet at the source of identity

  • Missing manager data: The source of identity is missing a manager value, but this information is required for downstream application provisioning

• Emergency access control:

  • Security incidents: Immediate access restrictions are needed before HR systems can be updated

  • Temporary access grants: Providing temporary access while permanent changes are processed

Before you configure identity override attributes, verify that override values comply with organizational policies and data standards, and assess the downstream impact of attribute changes. Ensure:

• You have administrative access to Veza Lifecycle Management

• You understand which source identity attributes need to be overridden

• You have identified the specific identities requiring attribute overrides

• You understand that overrides only affect Lifecycle Management workflows, not Access Visibility

Veza supports overrides for various property types from the source of identity:

• Text properties (e.g., Department, Manager, Job Title)

• Date properties (e.g., Activated At, Hire Date, End Date)

• Numeric properties (e.g., Employee ID)

• Boolean properties (e.g., Active status, Enabled flags)

You can view, create, edit, and delete overrides from the identity details view.

1. Click Lifecycle Management in the navigation sidebar, then select the Identities tab.

2. Locate the identity requiring an attribute override.

   2.1. Use the Search by name field to find the specific user

   2.2. Click on the identity name to show more information in the sidebar

   2.3 Click Details to open the expanded details view

3. Open the identity's Properties tab:

The identity details view provides visibility into both original and overridden values. A visual indicator will highlight any attributes with overrides:

1. Properties: Use this tab to show side-by-side comparisons of actual values from the source of identity and override values

2. Overview: This tab includes a consolidated view of all active overrides for an identity

To change the value of an attribute override:

1. Navigate to the identity's Properties tab. Access the same identity detail view where you created the override.

2. Locate the attribute with an active override. Find the attribute showing "yes" in the Override column.

3. Edit the override value.

   3.1. Click the Actions menu (three dots) for the overridden attribute

   3.2. Select Edit Override from the dropdown menu

3.3. Modify the Override Value in the dialog 3.4. Click Save to apply the changes

To remove an override:

1. Access the identity's Properties tab. Navigate to the identity detail view with active overrides.

2. Identify the override to remove. Locate the attribute with "yes" in the Override column.

3. Clear the override.

   3.1. Click the Actions menu (three dots) for the overridden attribute

   3.2. Select Clear Override from the dropdown menu

   3.3. Confirm the action when prompted

The attribute will revert to using the source of identity value, and the Override column will show "no".

The current implementation supports overrides at the individual identity level. Note that any attribute overrides are not reflected in the Veza Access Graph.

• Lifecycle Management only: Attribute overrides affect only Lifecycle Management workflows and policy execution

• Access Visibility unchanged: The Access Graph and Access Visibility features continue to use the actual source of identity values

• Source system independence: Overrides do not modify data in the originating identity providers or HR systems

You should typically use overrides as temporary measures while addressing root causes in source systems. Maintain clear records of why each override was implemented and the business justification.

Consider the following best practices when implementing attribute overrides:

• Regular review process: Establish periodic audits of active overrides to ensure they're still necessary

• Monitor policy impact: Review workflow execution logs to confirm that overrides produce expected policy outcomes. You can review the identity details Activity tab and the Lifecycle Management Activity page to ensure that override values are applied as expected during provisioning, deprovisioning, and other lifecycle actions.

• Emergency response procedures: Establish clear protocols for when and how to use overrides in approved scenarios.

Overview

Lifecycle Management runs a policy's workflows during the normal extraction cycle. To run a workflow outside that cycle, use Run Workflow Manually. For example, re-run a joiner workflow for a new hire, or apply a new workflow to identities that already exist.

You can run a workflow manually in two ways:

• For one identity: from the identity's ⋮ menu on the Identities page

• For multiple identities: from the workflow's card on the policy's published version

The two entry points have different availability rules. See When the option is unavailable.

A manual run also runs a workflow that is disabled in the policy, once, for the identities you select.

• Running a workflow manually requires the Administrator role. See .

• The policy's published version must contain at least one workflow.

1. Go to Lifecycle Management > Identities.

2. Open the ⋮ menu for the identity, on its row or in its details view.

3. Select Run Workflow Manually.

4. In the Manually trigger workflow for identity dialog, select a workflow from the Workflow list.

When the run is queued, a message confirms that the workflow was triggered for the identity. If the selected workflow has no actions, a warning states that the workflow has no actions, and nothing runs.

To follow the run, open the Workflow Tasks tab of the page. The Started Manually column shows Yes for manual runs.

Run a workflow for every identity in a policy, for identities you select, or for identities that match a filter.

1. Go to Lifecycle Management > Provisioning > Policies and open the policy.

2. In the Policy Versions panel, open the published version's .

3. Select the Workflows tab.

4. On the workflow's card, open the ⋮ menu and select Run Workflow Manually.

The filter uses the same syntax as workflow trigger conditions. See the . Select Identities based on properties is unavailable when the policy has no data source attributes.

Only run identities currently matching this workflow's condition is cleared by default, so the workflow runs for every selected identity. With it selected, Veza skips any selected identity that does not currently match the workflow's trigger condition.

A confirmation message states that tasks are being created for the selected identities. Select View Workflow Tasks to open the Workflow Tasks tab of the page, filtered to this run. For Select All and filter runs, tasks are created in the background, so the tab fills in as the run progresses.

On the Identities page, Run Workflow Manually appears only when the policy is running. A paused or initial policy does not qualify.

On a workflow card, Run Workflow Manually is unavailable when the workflow cannot be run manually, and a tooltip gives the reason:

Starting with Veza v2026.11.2, both entry points require an enabled policy, and a paused policy no longer qualifies. A manual run requested through the API for a policy that is not enabled returns an error. In earlier releases, a workflow card on a paused policy offers Run Workflow Manually, and its tooltip reads The policy must be enabled or paused to run a workflow manually.

Permanently removes user accounts from target systems. Unlike the DEPROVISION_IDENTITY action which disables or suspends accounts while preserving audit records, DELETE_IDENTITY performs complete account removal.

Example Use Cases:

• Database user cleanup after employee offboarding

• Compliance with data deletion policies (e.g., GDPR right to be forgotten)

• Removing test or temporary accounts

Identities are the core entities in Lifecycle Management. They represent the people in your organization, sourced from HR systems, identity providers, ITSM platforms, payroll systems, custom OAA applications, or flat files. See Integrations for the full list of supported identity sources.

In this section

Key concepts

• Source of Identity: The authoritative system (such as Workday or Okta) that provides identity data

• Identity Attributes: Properties like first name, last name, email, department, and manager

• Override Attributes: Custom attributes that can supplement or override source-provided values

• - How source attributes map to Veza

• - Computed attributes for advanced logic

Rotates cryptographic keys in Azure Key Vault by creating a new key version. The action targets one or more named keys in a specified vault and runs rotations concurrently (up to five keys in parallel). Each key's result is reported individually, so partial success is possible.

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.

Resets user passwords in target systems. Configuration options and behavior vary by integration.

Example Use Cases:

• Reset passwords for new users who must change on first login

• Enforce password rotation policies

• Recover from account lockouts

Overview

By default, only Administrators can create Access Profiles in Lifecycle Management. Administrators can grant the Creator permission set to specific users and groups, allowing them to create new profiles. Users who create a profile automatically become its Owner. Owners can edit the profiles they own, but not other profiles. Administrators retain full access to all profiles.

Creator is a single tenant-wide grant on Access Profiles. It is not scoped to an individual Access Profile Type.

Where a user can create Access Profiles depends on their role:

• Lifecycle Management: The Access Profiles pages require the Operator role, so only Operators can use Creator permission there.

• Access Hub: When the Access Profiles page is visible in , users with other roles who hold Creator permission can also create Access Profiles from that page. Administrators control whether the page is visible in .

• You have the Administrator role on the root team. An Administrator scoped to a sub-team cannot grant or revoke these permissions.

• To create Access Profiles from Lifecycle Management, the users receiving permissions have the Operator role. Users with other roles can create Access Profiles only from Access Hub.

• The users receiving permissions can see at least one Access Profile Type. See .

To assign Access Profile creation permissions to users or groups:

1. Go to Access Profiles > Access Profiles.

2. Click Settings.

3. On the Access Profile Settings page, go to the Permissions step.

   The step lists the users and groups that currently have creation permissions.

4. Click Add Permissions

Result: Users and groups with Creator permission can now create Access Profiles for each profile type they can see. To grant profile type visibility, see .

Creator permission alone does not allow a user to create an Access Profile. The user must also hold the Viewer permission set (not the Veza Viewer role) on at least one Access Profile Type. Without it, the type does not appear in the Create Access Profile form, and an API request specifying that type returns a not-found error.

To grant visibility of a profile type:

1. Go to Access Profiles > Access Profile Types.

2. Locate the profile type, then select Manage Permissions from its actions menu.

3. In Type, select USER or GROUP, then select the user or group in Name.

The permission applies as soon as you make a selection. There is no save step. See .

Viewer permission on the profile type is required even when Enable Multiple Access Profile Types is inactive and all Access Profiles use a single type. In that mode, the Access Profile Types page is not reachable from the navigation menu, so you cannot use its Manage Permissions action.

Instead, designate the user or group as an owner of an existing Access Profile that they are allowed to manage. Designating an owner automatically grants Viewer permission on that profile's type, and in this mode every profile uses the same type. At least one Access Profile must exist; if none does, an Administrator must create one first.

1. Confirm that the user or group already holds Creator permission. Only users and groups with Creator permission can be designated as owners.

2. On the Access Profiles > Access Profiles page, select Manage Owners from the actions menu of that Access Profile.

3. In the Manage Owners dialog, select USER or GROUP in Type, select the user or group in Name, and click Add.

Result: The user or group can select this profile type when creating an Access Profile.

To confirm that permissions were assigned correctly:

1. On the Permissions step of the Access Profile Settings page, review the list of assigned users and groups.

   Each row shows the user or group name and its type.

2. Assigned users should now see the Create button on the Access Profiles page.

3. Users without permissions will not see the Create button.

To revoke Access Profile creation permissions:

1. Go to Access Profiles > Access Profiles and click Settings.

2. Go to the Permissions step.

3. Locate the user or group to remove.

4. Click the Remove Permission (trash can) icon next to the user or group. The permission is removed immediately, with no confirmation prompt. You do not need to click Save.

Result: The user or group can no longer create new Access Profiles or be designated as an owner, unless the user holds Creator permission through a group. They keep Owner permissions on profiles they own, and read-only access to other existing profiles.

• - Overview of the permission sets system

• - Understanding Access Profiles and their role in Lifecycle Management

• - Profile type configuration and visibility permissions

• - Veza role definitions and capabilities

Queries the Veza Access Graph for entities during workflow execution. This is a read-only lookup that does not create or modify entities. Retrieved nodes are available to subsequent actions and conditions in the workflow.

Example Use Cases:

• Verify a user exists and is active in a target system before submitting a provisioning request (e.g., check that an OktaUser is active before assigning an application)

• Look up entity attributes from the graph to use in downstream transformer expressions

• Check if a role or group exists before attempting to assign it

The SCIM filter supports dynamic template variables (e.g., {attribute_name}) that resolve at runtime using values from previous actions. See for details on template syntax.

Rather than re-running an identical query on every execution, Get Node From Graph can reuse a result Veza already computed. A stored result is reused only while it is less than five minutes old, measured from the time that result completed. Past five minutes the action runs a new query, so workflows act on values from the most recent extraction instead of a day-old snapshot.

This five-minute bound is specific to Lifecycle Management graph reads. Other callers of the same query service use its default of 24 hours, which is what this action used before the bound was introduced.

Two related behaviors affect what a workflow sees:

• When a matching query is still running, the action uses that query's result rather than starting another, regardless of when the query began.

• Lifecycle Management keeps a separate ten-minute cache for the single-node lookups used by other actions, such as relationship management. The five-minute bound applies to this action's queries and does not shorten that cache.

The staleness window is not configurable.

This example shows a workflow that checks if a user exists and is active in Okta before submitting a provisioning request:

1. Trigger condition: employment_status eq "ACTIVE" — fires for new hires or active employees

2. Get Node From Graph action: Query for OktaUser with filter email eq {email} — looks up the user by their email address in the Okta integration

3. Condition Expression: OktaUser.is_active eq true checks the

Each retrieved node is an entity from the Access Graph with the following data:

Retrieved nodes are added to the workflow context and can be used in three ways:

Add a condition after the action and set its Condition Type to When this condition matches. The condition expression is evaluated against the source identity and the nodes that earlier actions retrieved, so it can reference a retrieved node's attributes by prefixing them with the entity type (for example, OktaUser.is_active eq true). The condition controls which subsequent actions execute.

Subsequent Get Node From Graph or actions can reference retrieved node attributes in their SCIM filters and payloads using transformer template variables. The transformer service resolves {EntityType.attribute} expressions against the accumulated nodes.

For example, if a Get Node From Graph action retrieved an OktaUser node with login = "jsmith@company.com", a subsequent action's filter could reference {OktaUser.login} to use that value.

Note: The entity type prefix is case-sensitive and must match the graph type exactly (e.g., OktaUser, not oktauser). Attribute names are case-insensitive.

Multiple Get Node From Graph actions can run in sequence. Each action's results accumulate in the workflow context, so later actions and conditions can reference nodes from any earlier action. This enables multi-step lookups — for example, first look up a user, then look up their manager.

Veza's Lifecycle Management (LCM) solution empowers organizations to automate and streamline the management of user identities and access rights throughout the employee lifecycle. From onboarding to role changes and offboarding, automated LCM workflows ensure that the right people have the correct access at the right time.

Key features

• Automated Provisioning and De-provisioning: Streamline granting and revoking entitlements as employees join, move within, or leave the organization

• Environment-wide Synchronization: Keep user attributes and access rights consistent across applications and platforms

• Customizable Workflows: Design tailored processes for different lifecycle events and user segments

• Compliance and Audit Support: Maintain detailed records of access changes to support compliance and audit efforts

• Integration with Identity Providers: Integrate with identity providers and HR systems, import HR data from CSV, or use a custom OAA template

Reference documentation:

• - Conceptual guide to the different evaluation systems

• - SCIM filter syntax for workflow conditions

• - Complete list of transformation functions

• - Formatter-based profile assignment

Policies define the rules and actions for managing identities throughout their lifecycle. They specify what actions should occur when there are changes in a source of identity, such as when a user is created or their attributes change.

After configuring a policy for a source of identity in your organization, Veza Lifecycle Management tracks the source for changes. When employee records are added or changed, actions will trigger based on the workflows and actions specified in the policy. Learn more about .

Workflows are sequences of actions within a policy that execute based on specific conditions. They enable automation of lifecycle management processes such as onboarding, role changes, and offboarding.

Workflows only execute actions on users that meet specific conditions, and Policies can contain more than one Workflow. This enables you to create a single policy for your source of identity that contains multiple workflows, with one applying to new hires, another applying to terminated employees, and so on for the different JML scenarios you want to automate. Learn more about .

Access Profiles define sets of entitlements (such as group memberships or role assignments within a target application) that should be granted to users based on their role within the organization (or another distinguishing attribute). You can use Access Profiles to define both Business Roles – segments of employees, and Profiles – collections of entitlements in a target application.

Assigning Business Roles to the Profiles they should inherit enables you to define the birthright entitlements for different types of employees in your organization. You can then assign those Business Roles when configuring workflows that add or remove access to an application. Learn more about .

Lifecycle Management Actions are tasks performed within a workflow, such as creating a user account, assigning group memberships, or disabling an account. Actions can be combined to trigger in sequence when there are changes in the source of identity. Actions can run for any identity that meets the workflow conditions, or only apply when action-level conditions are met. Learn more about available .

Transformers allow you to modify and format user attributes when synchronizing data between systems, ensuring consistency and compatibility when creating users across applications.

Lifecycle Management will provision new users with these attributes and can keep their accounts up-to-date when there are changes in the source of identity. Target entity attributes can be set to specific values or use metadata from the source of identity, and support a range of transformation functions. Learn about .

Lifecycle Management uses several systems that evaluate identity attributes, each serving a distinct purpose:

• Workflow Conditions: SCIM filter expressions that determine whether workflows and actions execute (e.g., is_active eq true). Output is boolean.

• Attribute Transformers: Formatter expressions that determine what value an attribute should have (e.g., {first_name | UPPER}). Output is a string.

• Dynamic Access Profiles: Formatter expressions that resolve to Access Profile names at runtime (e.g., dept-{department | LOWER}

These systems can work together. For example, workflow conditions can embed transformer syntax for dynamic date comparisons. For a guide to when and how to use each, see .

Customize email notifications sent during Lifecycle Management events and Access Request workflows. You can personalize messaging, add branding, and include event-specific information through placeholders. Learn more about .

1. Enable Integrations: Configure your data sources and enable them for Lifecycle Management.

2. Define Access Profiles: Create profiles that map your organizational structure to application-specific entitlements.

3. Create Provisioning Policies: Automate identity management processes. See .

4. Configure Workflows: Design workflows within policies to handle specific lifecycle events.

For an overview of Lifecycle Management configuration using Okta, Workday, and Active Directory, see .

For API documentation, see .

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 . When a workflow runs and conditions match, Veza queues and creates an access review campaign based on the configured certification plan.

Use LCM-triggered access reviews to:

• Automatically certify access when employees change roles (movers)

• Review permissions before offboarding (leavers)

Start here to understand Lifecycle Management fundamentals, monitor your LCM environment, and track workflow execution.

Introduces a deliberate delay in the workflow execution.

Example Use Cases:

• Allow time for system propagation between actions

• Implement rate limiting in multi-step workflows

• Coordinate timing with external processes

After a bulk dry run completes, review its results to confirm which workflows matched, which attribute values would change, and whether any identity produced errors. A bulk dry run evaluates a policy version against many identities and records what would happen, without contacting the target systems.

To start a dry run, see .

• A bulk dry run has completed. See .

• You have the Administrator or Operator role. See .

You can open the results of a bulk dry run in these ways:

Automatically creates access review campaigns during lifecycle events. This action bridges Lifecycle Management with Veza Access Reviews, enabling automated certification workflows triggered by identity lifecycle changes.

Example Use Cases:

• Review contractor access 30 days after onboarding to ensure appropriate permissions

• Certify elevated permissions after role changes or promotions

• Trigger periodic access reviews based on employment anniversaries

Test evaluates a condition or a formatter against sample attribute values, in the workflow editor or in a policy version's read-only view. It does not run the workflow.

Two dialogs are available:

• A workflow trigger condition or a condition node, in the Test Condition dialog

• An attribute formatter, in the Test Formatter dialog

Both dialogs are available in the workflow editor. They are also available in the read-only view of a policy version, except for the formatters listed in .

Controls entitlements such as group memberships and role assignments for identities.

Example Use Cases:

• Add users to appropriate security groups, roles, permission sets, or other access-grant entities

• Remove users from groups during role changes

• Update entitlements when employees move between departments

Updates a Human Resources Information System (HRIS) or other identity source with an email address created earlier in the same workflow. This ensures the source of identity (such as Workday) contains the employee's new corporate email address, and keeps records consistent across systems.

The address comes from an upstream action, usually Create Email. This action has one setting, Entity Type: you choose where the address is written, not what gets written. It writes the address the upstream action produced without modifying it, so you cannot select among several addresses or reformat one. To set the identity source's email to a value you choose, use Provision Account instead.

Example Use Cases:

• After creating an Exchange Server mailbox during onboarding, write the new email address back to the Workday Worker record

• Update an OAA-based HRIS source with email addresses generated by provisioning workflows

Supported Integrations:

A workflow containing a Write Back Email action must also contain an action that produces an email address, earlier in the same workflow branch. Two kinds of action qualify:

• A Create Email action.

• A Provision Account action against an integration that provisions a mailbox as part of the sync. Google Workspace is the only integration that provisions a mailbox this way.

Veza checks this when you publish or update the policy and rejects a workflow that does not satisfy it, rather than letting it fail during a run. This check applies to Write Back Email actions only, and it validates the structure of the workflow rather than what happens during a run. A workflow that passes the check can still fail at run time. If a condition skips the upstream action, or its sync does not surface the provisioned address, the Write Back Email action records an ACTION_FAILED event in the activity log.

This requirement is why a workflow that provisions Active Directory or Azure AD from Workday cannot use Write Back Email unless it also creates a mailbox. Provisioning an Active Directory or Azure AD account does not by itself produce an email address that this action can write. To write an address back to Workday in those workflows, map email on a write-back action.

Both can set an identity source's email address, and for Workday both write the same field. They differ in where the value comes from.

Choose Write Back Email when the workflow provisions the mailbox and you want that address in the HRIS. Choose Provision Account when the authoritative address comes from another system: an account Veza created in Active Directory or Azure AD, a downstream IdP, or another HRIS field. For a Workday example that reads the address from the Access Graph, see .

In a typical Workday-to-Active Directory onboarding workflow, Write Back Email is the third step:

1. Provision Account creates the AD user account from the Workday Worker.

2. Create Email creates an Exchange Server mailbox, generating the email address.

3. Write Back Email writes the new email address back to the Workday Worker record.

4. A second Provision Account action, targeting Active Directory and mapping only email, sets the address on the AD user account.

This ensures that the Workday record reflects the employee's corporate email immediately after onboarding, without manual HR data entry.

For the full workflow configuration, see the in the Actions overview. For Exchange Server setup, see .

Creates email accounts for identities through integrated email providers. This action is typically used in onboarding workflows alongside Provision Account and Write Back Email to provision a user account, create their email, and update the HR system with the new address.

Example Use Cases:

• Create Exchange Server mailboxes for new employees during onboarding

• Provision Azure AD email accounts as part of identity lifecycle workflows

• Generate email addresses using transformer-based formatting (e.g., {first_name}.{last_name}@company.com)

Supported Integrations:

In a standard onboarding policy, Create Email is used as the second step after creating the user account:

1. Provision Account creates the user account in Active Directory or the target system.

2. Create Email creates the email account in Exchange Server, generating the email address using attribute transformers.

3. Write Back Email updates the source of identity (for example, Workday) with the newly created email address.

4. A second Provision Account action, targeting Active Directory and mapping only email

See the in the Actions overview for a complete workflow.

These guides provide step-by-step instructions for common Lifecycle Management tasks and configurations.

In this section

• - Common questions and troubleshooting

• - Architecture overview

• - Monitor workflow execution and policy status

Executes integration-specific operations that extend beyond standard Lifecycle Management action types. CUSTOM_ACTION enables integrations to define specialized operations with flexible attribute schemas tailored to their unique capabilities.

Example Use Cases:

• Insert records into ServiceNow tables when employees join or change roles

• Create ServiceNow incidents or requests as part of onboarding workflows

• Update ServiceNow CMDB records during employee lifecycle events

• Log audit records for compliance tracking

Supported Integrations:

For detailed configuration examples including incident creation and audit logging, see .

This guide explains how to disable individual workflows or actions within a Provisioning Policy. Disabling allows you to temporarily pause specific parts of a policy without deleting or modifying the underlying configuration.

Use this option when developing workflows to support:

• Managing gradual rollouts: Enable actions one at a time to verify each step before activating the next

• Troubleshooting issues: Isolate problematic actions without removing configuration

Lifecycle Management automates identity provisioning across your applications. When an employee joins, changes roles, or leaves, workflows answer two questions: Should this person get access? And what should their account look like?

This document explains the building blocks: conditions that control when things happen, and transformers that control what values are set.

Terminology

These terms are used throughout Lifecycle Management documentation.

Purpose: Determine whether a workflow should execute based on identity attributes.

Syntax: SCIM filter expressions that evaluate to true or false.

Example:

When to use: Gate workflow execution based on identity state, department, location, employment type, or other attributes.

See for complete syntax documentation.

Purpose: After a workflow trigger matches, determine whether subsequent actions should run.

Syntax: Same SCIM filter syntax as workflow triggers.

Example:

When to use: Create branching logic within a workflow where different actions apply to different identity subsets.

See for configuration details.

Purpose: Construct attribute values when syncing identities to target systems.

Syntax: Formatter templates with optional pipeline functions.

Examples:

When to use: Transform source attributes into the format required by target systems (usernames, email addresses, distinguished names, etc.).

Transformers also support IF/ELSE conditional logic to select different values based on identity attributes. See for complete documentation.

Purpose: Dynamically determine which Access Profile to assign based on identity attributes.

Syntax: Formatter templates (same as attribute transformers) that resolve to Access Profile names.

Example:

If user's department is "Engineering", this resolves to the Access Profile named dept-engineering.

When to use: Assign Access Profiles based on department, location, role, or other attributes without creating separate workflow conditions for each combination.

See for complete documentation.

Conditions and transformers can work together. Workflow trigger conditions can embed transformer syntax for dynamic value comparisons.

This condition triggers a leaver workflow when an employee's last day falls within a 2-day window around today:

Breaking it down:

The syntax {\| FUNCTION \| ...} (pipe immediately after opening brace) indicates a transformer with no source attribute—it starts directly with a function like NOW.

See for more examples.

• - Complete SCIM syntax for workflow triggers

• - Formatter syntax and pipeline functions

• - All available transformation functions

• - Formatter-based profile assignment

The Lifecycle Management Dashboard provides a centralized interface for monitoring automatic provisioning and deprovisioning of user access - both birthright access granted by Veza Lifecycle Management and just-in-time access granted by Veza Access Reviews. This dashboard gives you an at-a-glance view of your configuration, status, and recent activity.

The dashboard is the primary landing page for Lifecycle Management and Access Requests and can help with routine monitoring, error resolution, policy validation, activity review, and integration health checks.

Dashboard Overview

The dashboard is organized into several key sections:

• Provisioning Policies: Shows the total number of policies and up to three of them with their status

• Access Profiles: Shows configured Access Profiles and usage metrics

• Identities: Provides a visualization of managed identities

• Integrations: Top enabled for Lifecycle Management and Access Requests along with any error statuses

• Access Requests: Tracks pending and completed access requests

• Errors: Displays recent Lifecycle Management and Access Requests errors requiring attention (past day, week, or month)

• Recent Activity: Shows the most recent Lifecycle Management and Access Requests

To navigate to more detailed information, click on any section heading to open the related overview. Click on specific items (such as a policy or integration) to view or edit configuration details.

From the dashboard, you can perform common tasks including:

• Create a new policy: Click Create Provisioning Policy in the Provisioning Policies section

• Configure Access Profiles: Click the "Create Access Profile" button in the Access Profiles section

• Set up a new integration: Click the "Set up Integration" button in the Integrations section

• Monitor system health: Review the Errors section for any issues

The Provisioning Policies section shows the total number of policies and lists up to three of them. Each listed policy shows its name, associated identity source, number of identities managed, and current status, for example Running or Stopped. When more than three policies exist, select View all to open the full list.

You can create new policies with the Create Provisioning Policy button, see which policies are actively running, access detailed configuration by selecting a specific policy, and verify that policies in "Running" status should be active. Learn more about .

The Access Profiles section shows the total number of configured access profiles and provides a visual representation of profile activity. Access profiles define sets of entitlements granted to users based on their roles.

You can see the total number of configured profiles, create new ones using the "Create Access Profile" button, view profile activity and utilization, and access detailed configuration by clicking into the section. Learn more about .

The Identities section provides a visual representation of all identities managed through Lifecycle Management and Access Requests. The chart displays the distribution of identities by type or status, giving you an immediate understanding of your identity landscape.

This visualization helps you understand the overall composition of your managed identities, identify distribution patterns across different categories, and track changes in identity distribution over time.

The Integrations section lists all systems connected to Lifecycle Management and Access Requests, displaying the total number of integrations, error status and counts, recently created integrations, and last update timestamps. For each integration, you can see its name and type, current status (including error indicators), and last update timestamp. You can set up new integrations using the "Set up Integration" button, identify and troubleshoot integration errors, and view all integrations by clicking "View all." Review this section regularly to identify any integrations with error states. See for more information.

The Access Requests section tracks pending access requests, recently completed requests, and request status (Pending, Completed, Rejected, Cancelled). This section provides visibility into the access request process, allowing you to monitor request volume and status, track completion rates, and identify potential bottlenecks in the access request workflow.

The Errors section displays any Lifecycle Management and Access Requests errors that require attention. When functioning normally with no issues, this section will display "No issues found." If errors occur, this section will list the specific errors, provide context about when and where they occurred, and offer guidance on troubleshooting and resolution. Check this section regularly for any reported issues.

The Recent Activity section shows a chronological log of Lifecycle Management and Access Requests events, including event type, timestamp, affected identity, and entity name. Examine this section to identify any unusual patterns or failed operations. This activity log helps you track recent actions, verify that expected changes have occurred, identify patterns or issues in lifecycle events, and monitor the overall health of your Lifecycle Management or Access Requests implementation.

After familiarizing yourself with the dashboard:

Disables or suspends user accounts in target systems when employees or contractors leave the organization. Unlike Delete Account, which permanently removes accounts, Deprovision Account preserves the account and its audit history while revoking access — allowing for potential reactivation if needed.

Example Use Cases:

• Disable Active Directory accounts and move leavers to a terminated users OU

• Suspend Okta accounts while preserving group membership history for audit

• Revoke access and reassign resources when employees transition out of the organization

• Lock accounts during investigations while maintaining forensic records

The exact deprovisioning behavior depends on the target application and the method configured in the action. Integrations may support one or more of the following:

Not all integrations support both methods. The Deprovision Type dropdown lists the methods the integration supports, and appears only when more than one is available.

See the in the Actions overview for a complete Active Directory offboarding configuration.

Use Compare Versions to view what changed between two before you publish a draft, or to review how a policy changed over time. The comparison lists every added, modified, and removed item, grouped by the part of the policy it belongs to, with the value in each version side by side.

For the layout of the policy page and the , see .

• The policy must have more than one version. For a policy with one version, the ⋮ menu on the Provisioning Policies page still shows Compare Versions, but the comparison shows only Pick two different versions to see a comparison.

• Comparing versions requires the Administrator or Operator role. See .

The Create with AI button in the Lifecycle Management workflow editor, and on a shared attribute mapping's edit panel (a Transformer in earlier releases), opens the Access AI panel for the LCM Policy Agent. Describe the condition or the transformed value you want in plain language, and the agent suggests the matching syntax with a short explanation. The suggestion appears as an action card in the Access AI panel, and you decide whether to apply it. Applying a suggestion updates the form field only. Saving the workflow or the shared attribute mapping saves the change.

The button appears next to these fields:

• Condition strings

  • The Identity matches this condition

Overview

Lifecycle Management supports four 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 Payload 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

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

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

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 .

• 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

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

You can use 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.

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

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

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.

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

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

• : Overview of integration pathways (Native, SCIM, OAA Write Framework, and direct REST, XML, and SQL actions)

• : Action configuration, variable substitution, and response handling

• : Centralized authentication management for Send REST Payload actions

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

Creates entitlements (groups, roles, or distribution lists) in target systems. This action supports creating new entitlements, renaming existing ones, and synchronizing entitlement membership. It is not offered in the workflow editor. Run it from the Create Entitlement option in an integration row's action menu under Lifecycle Management > Integrations. The Activity page lists it as Create Group.

Example Use Cases:

• Create department-specific Active Directory security groups

• Provision Okta groups for new teams or projects as part of organizational changes

• Create Azure AD distribution groups for new departments

• Create AWS IAM Identity Center groups for team-based access management

• Automatically add newly created entitlements to Access Profiles for downstream provisioning

When an existing entitlement ID is provided, the action renames the entitlement rather than creating a new one. This is useful when organizational changes require updating group or role names while preserving existing membership and access.

When Sync Members is enabled, the action compares the current entitlement membership against the expected member list and:

• Adds members that should be present but are missing

• Removes members that are present but should not be

• Tracks individual member operations, reporting successes and failures separately

This enables precise entitlement membership management as part of lifecycle automation.

Newly created entitlements can be automatically added to an . This enables workflows where creating an entitlement in one step makes it available for assignment in subsequent Manage Entitlements actions, connecting dynamic entitlement creation with birthright access provisioning.

CREATE_ENTITLEMENT generates three notification event types:

You can configure email notifications or webhooks for these events. See for configuration details.

This guide explains how to configure an Access Profile Type that creates local user accounts in a target system without adding relationships to specific entitlements (such as groups, roles, or permissions).

Use this approach when you need to:

• Provision user accounts for application access without granting specific roles or group memberships

• Create accounts that will receive entitlements later through a separate process (such as manual assignment or another workflow)

• Support "application access only" scenarios, where the goal is a working account rather than entitlement-level access