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

In this section

Reference documentation:

• - Conceptual guide to the different evaluation systems

• - SCIM filter syntax for workflow conditions

• - Complete list of transformation functions

Core concepts

Policies

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

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

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 .

Actions

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 .

Attribute transformers

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 .

Conditions and transformers

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.

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 .

Notifications

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 .

Getting started

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 Policies: Add policies to automate identity management processes.

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

For API documentation, see .

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

Overview

This guide explains how to disable individual workflows or actions within a Lifecycle Management 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

• Implementing seasonal policies: Temporarily disable workflows that only apply during certain periods

• Workflow Testing: Disable production actions while testing new workflow logic

Disable a workflow

Disabling a workflow prevents it from running during policy execution. All conditions and actions within the workflow are also skipped.

1. Go to Lifecycle Management > Policies.

2. Select a policy and click Edit Workflow.

3. Toggle the workflow's Enabled control to disabled.

The policy editor displays disabled workflows and actions with a "Disabled" tag.

Disable an action

You can also disable specific actions within a workflow without disabling the entire workflow. When you disable an action, any nested conditions and actions under the disabled action are also skipped, but other actions in the workflow continue to run normally.

1. Open the workflow editor.

2. Select the action you want to disable.

3. Toggle the Enabled control in the action settings.

4. Click Save

Test disabled workflows with dry run

Disabled workflows are evaluated by default during dry run simulations. This allows you to preview what would happen if you re-enabled a disabled workflow and validate trigger conditions and action configurations before making them active.

When you run a dry run simulation, the results show what actions would run if the workflow were enabled.

Re-enable a workflow or action

To re-enable a disabled workflow or action, toggle the Enabled control back to enabled and save.

See also

Updates HRIS or identity source systems with email addresses created by previous Create Email actions in the same workflow. This ensures the source of identity (such as Workday) has the employee's new corporate email address, keeping records consistent across systems.

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:

Example: Exchange Server onboarding with email write-back

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

1. Sync Identities — creates the AD user account from the Workday Worker

2. Create Email — creates an Exchange Server mailbox (generates the email address)

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

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 .

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 .

Triggers email notifications and webhooks based on lifecycle events and action success or failure. Notifications can be added to any action type under Edit Action > Action Notification Settings.

Example Use Cases:

• Alert IT staff when provisioning is complete

• Notify managers of access changes

Disables or suspends user accounts in target systems when employees or contractors leave the organization. Unlike , which permanently removes accounts, Deprovision Identity 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

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 a JiraUser is active before creating a Jira ticket)

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

Example: Verify Jira User Before Provisioning

This example shows a workflow that checks if a user exists and is active in Jira 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 JiraUser with filter email eq {email} — looks up the user by their email address in the Jira integration

Output and Downstream Usage

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:

1. Condition branching

Use to check whether the action returned any nodes of a given type, or to check the graph directly. These conditions control which subsequent actions execute.

2. Filter template variables in subsequent actions

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 = "[email protected]", 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.

3. Chaining multiple graph lookups

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.

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

Overview

This guide explains how to use dry run simulations to test Lifecycle Management policies before enabling them in production. Dry run evaluates workflow logic and shows what actions would occur without making actual changes to target systems.

Use dry run testing to:

Makes HTTP requests to external APIs and services as part of provisioning workflows. This action enables integration with custom applications, webhooks, and REST-based services that support identity management operations.

Example Use Cases:

• Notify external systems when users are created or updated in target systems

• Trigger custom provisioning workflows in third-party applications

• Send identity data to SCIM endpoints for user synchronization

• Create service desk tickets for manual provisioning steps

• Execute webhooks to coordinate multi-system workflows

• Extract response data (like user IDs) from external systems for use in downstream actions

Variable Substitution

When constructing the webhook URL and JSON payload, you can reference identity attributes using curly brace syntax. Two sources of attributes are available specifically for this URL and payload context:

• Source-of-identity (SOI) attributes: Attributes from the identity source triggering the workflow (e.g., Workday worker fields, Okta user attributes).

• Sync Identities output entity attributes: When a Sync Identities action precedes this action in the same workflow, attributes from the provisioned or updated target user (such as Active Directory user attributes) are also available. See below.

Available transformations include UPPER, LOWER, TRIM, and accessing nested attributes with dot notation, such as {Manager.email}. See for complete transformation syntax.

Note: If any placeholder in the URL or payload cannot be resolved (e.g., due to missing attributes), the entire transformation is skipped and the original URL is used without any substitution. The system logs a warning for troubleshooting. Ensure all referenced attributes exist in the source of identity to enable proper variable substitution.

Form field substitution (Access Requests only)

When a Send REST Request action is configured as part of an Access Request , the JSON payload can reference form field values submitted by the requester. This enables dynamic payloads where the requester provides values (such as a role name or resource ID) at request time, and those values are injected into the API call.

Use the {$form_field.field_name} syntax in the JSON payload, where field_name matches a field defined in the catalog definition's form fields.

To configure form field substitution:

1. Create a Send REST Request action in a provisioning policy with placeholders in the JSON payload:

2. Create a Send REST Payload and add form fields with names that match the placeholders (e.g., role_name, role_id).

3. When a user submits an access request using this catalog definition, they fill in the form fields. The submitted values replace the corresponding {$form_field.*}

Form field substitution applies to the JSON payload only. It does not apply to the webhook URL or authorization header. Field names must contain only letters, numbers, and underscores (role_name is valid, role-name is not). If a placeholder references a field that was not provided in the access request, the placeholder is left unchanged in the payload.

Standard Active Directory attributes available for substitution

The following attributes are populated on the sync_identities output entity for Active Directory integrations and can be used in variable substitutions:

Custom properties defined in the integration configuration are also available, using the key customprop_<property_name> (where <property_name> is the property's format name as configured).

Response Handling

When "Add Response to Output Entities" is enabled, the action parses JSON responses and extracts specified entity data. This enables chaining actions where one API call creates a resource and returns an identifier that subsequent actions can reference.

For example, if a user creation API returns:

Configure the action with:

• Response Entity Attribute: result

• Response ID Attribute: user_id

• Response Name Attribute: display_name

The extracted entity becomes available to downstream workflow actions.

HTTP Method Guidelines

• GET: Query operations, typically without payload; use for checking resource state or retrieving data. Does not set workflow change flags

• POST: Create new resources; requires JSON payload; sets both AnyCreated and AnyChanges flags that can trigger downstream actions with "Only Send if Any Upstream Changes" enabled

• PUT

Workflow Integration: The AnyCreated and AnyChanges flags enable conditional workflow execution. Actions configured with "Only Send if Any Upstream Changes" will only execute when a previous action has set these flags, allowing you to build sophisticated conditional workflows (e.g., only send a notification webhook if a user was actually created, not just updated).

Authentication Patterns

The authorization header supports common authentication methods:

• No Authentication: Leave the authorization header empty when connecting to endpoints that don't require credentials, such as internal services or pre-authenticated URLs

• Bearer Token: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

• API Key: X-API-Key: secret-key-123 or Authorization: ApiKey sk-prod-xyz

Limitations

• Only JSON payloads are supported (no XML, form-data, or other formats)

• Authentication must be header-based (OAuth flows requiring user interaction are not supported)

• Response parsing requires valid JSON if "Add Response to Output Entities" is enabled

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

In this section

Where to go next

After reviewing the getting started materials:

1. Configure Integrations: Enable your identity sources and target applications for LCM. See .

2. Set Up Identities: View and manage identities from your configured sources. See .

3. Create Access Profiles: Define birthright entitlements for user segments. See .

For an end-to-end walkthrough using Workday, Okta, and Active Directory, see .

When creating Lifecycle Management Policies, you can configure workflows that define actions to execute during different employment lifecycle scenarios, such as when an employee is onboarded, changes function or role, or is withdrawn from the organization. Actions can be executed in sequence based on specific conditions, enabling you to automate onboarding and offboarding actions within Lifecycle Management, across systems in your environment.

Understanding Policies, Workflows, and Actions

Policies and workflows define how Veza automates identity management tasks across your environment by describing conditional actions to execute for different employee populations.

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

Creates entitlements (groups, roles, or distribution lists) in target systems as part of lifecycle workflows. This action supports creating new entitlements, renaming existing ones, and synchronizing entitlement membership.

Example Use Cases:

• Dynamically create department-specific Active Directory security groups during onboarding

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

Dynamic Approvers is an Access Requests feature that lets Veza automatically determine who should approve an access request based on runtime context, access profile metadata, and external data.

Instead of assigning static approvers in a policy, you will configure a transformer pipeline that processes request attributes, access profile properties, and lookup tables to compute approver email addresses when the request is submitted.

Use Dynamic Approvers when approval routing will depend on metadata that can vary per request. For example, this can enable workflows in which Access Profiles assigned a specific cost center are routed to the appropriate approver group, or to assign managers based on department code.

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

Before you start

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

Configure identity override attributes

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)

Create attribute overrides for individual identities

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

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

Update existing overrides

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.3. Modify the Override Value in the dialog 3.4. Click Save to apply the changes

Cancel attribute value overrides

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

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

Important considerations

Override scope and limitations

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

Operational best practices

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 Lifecycle Management Activity Logs 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.

See also

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 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 integration in Veza with at least one successful extraction

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

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.

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 (

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

Group Management:

• GET /Groups - List groups

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

• POST /Groups - Create new groups

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:

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.

* One of scim_token or the username/password pair is required for authentication.

Example Configuration with Bearer Token:

Example Configuration with Basic Authentication:

Push OAA Payload

Push the OAA Application Payload as normal. See the for details.

Entity Types and Identity Mapping

Veza creates entities in Access Graph based on the OAA payload, which can be targeted in lifecycle management operations:

• local_users in your Application template → Users to provision via SCIM

• local_groups in your Application template → Groups to manage via SCIM

Entity types are named according to the following pattern:

• User Entity Type: OAA.{application_type}.User

• Group Entity Type: OAA.{application_type}.Group

Where {application_type} is the value you specify in your OAA Application template when building the payload. For example, if the application is defined:

The resulting entity types are:

• OAA.CustomerPortal.User

• OAA.CustomerPortal.Group

Attribute Synchronization

Mapping OAA to SCIM

When Veza provisions users via SCIM, transformers can map attributes from your policy source of identity to SCIM properties:

Extension Attributes

If the SCIM service exposes a /Schemas endpoint and you enable scim_extension_schemas: true, Veza can synchronize custom extension attributes beyond the standard SCIM user schema. Extension attributes are mapped using the schema URN as defined by your SCIM implementation.

Provisioning Operations

The following SCIM operations are performed when Lifecycle Management actions execute:

Sync Identities (Create User)

Create a new user in the target application.

SCIM Operation:

The SCIM endpoint creates the user and returns the user object with an assigned id.

Sync Identities (Update User)

Updates an existing user's attributes (one-time or continuously).

SCIM Operations:

1. Query for existing user:

2. Update the user:

De-provision Identity

Remove access when a user leaves the organization or changes roles. The user account is deactivated, but data is preserved.

SCIM Operation:

Deprovision sets active=false, which disables login but preserves the user record.

Delete Identity

Permanently remove a user account.

SCIM Operation:

Manage Relationships (Add User to Group)

Grant a user access via group membership.

SCIM Operations:

1. Retrieve group details:

2. Add user to group:

Manage Relationships (Remove User from Group)

Revoke a user's access by removing group membership.

SCIM Operation:

Create Entitlement (Create Group)

Creates a new group so that it can be granted as an entitlement.

SCIM Operation:

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

In this section

Additional resources

• - Common questions and troubleshooting

• - Architecture overview

• - Monitor workflow execution and policy status

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

Supported Integrations:

Password output (Early Access)

When password output is enabled, the new password generated by this action is available to subsequent workflow actions via transformer expressions. Use {EntityType.password} syntax, such as {ActiveDirectoryUser.password} in a Send REST Request payload.

This is useful in workflows where a password reset must be confirmed or forwarded to an external system, such as an employee self-service portal.

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

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

• Service account lifecycle management (NHI)

• Contractor account removal after project completion

Supported Integrations:

• Active Directory (Users and Managed Service Accounts)

• Okta

• Google Cloud (Google Workspace Users)

• PostgreSQL

Overview

This page covers the integrations that power Lifecycle Management workflows and can act as identity sources for LCM policies, and target applications that can be provisioned or deprovisioned.

Enabling provisioning on an integration also makes it available to other Veza products that use write-back capabilities, including Access Intelligence (Disable Accounts) and Access Requests. The integration tables below represent the validated, production-ready set for Lifecycle Management specifically.

Veza supports three primary implementation pathways:

Overview

Fallback formatters can help resolve conflicts when provisioning identities with unique attributes. This is particularly useful when automated provisioning requires unique identifiers, but the standard generated values are already in use.

Synchronizes identity attributes between systems, with options to:

• Create new identities if they don't exist

• Update attributes of existing identities

• Enable continuous sync to keep attributes aligned with the source of truth

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.

Example Use Cases:

• Rotate Azure Key Vault keys on a scheduled basis to meet compliance requirements

• Automatically rotate keys when a service account is offboarded

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 for the full list of supported identity sources.

In this section

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: