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

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

In this section

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 .

4. Build Policies

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

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

Disabling a workflow pauses it. The workflow does not run during policy execution, and Veza skips all conditions and actions within it. During the pause, Veza retains each identity's trigger history, the birthright access profiles the workflow granted, and its failure and retry state.

1. Go to Lifecycle Management > Policies.

2. Select a policy and open its draft: click Create Draft, or Go to Draft Version if a draft exists. On the workflow's card, open the ⋮ menu and select Workflow Settings.

3. Turn off the Enable Workflow toggle.

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

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. Turn off the Action Enabled toggle in the action settings.

4. Click Save.

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.

To re-enable a disabled workflow or action, turn the Enable Workflow toggle (in Workflow Settings) or the Action Enabled toggle (in the action settings) back on and save. A re-enabled workflow does not run again for identities it processed before you disabled it.

By default, only Administrators can create Access Profiles in Lifecycle Management. With Access Controls enabled, Administrators can grant Creator permissions to specific Operators and Groups, allowing them to create new profiles. Users who create a profile automatically become its Owner and can edit that profile, but cannot modify profiles created by others. Administrators always retain full access to all profiles.

Users must have the Operator role to use Creator permissions — non-Operator roles (Access Reviewer, Watcher, etc.) cannot create Access Profiles even with explicit permission grants.

• You have the Administrator role on the root team

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 .

Updates an HRIS or 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 . 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 instead.

Example Use Cases:

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

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

• Automatically review access for high-risk roles or sensitive systems

• Create access reviews when users join specific departments or teams

The Create Access Review action editor contains the following settings, stored in the action's certification_creation_plan object:

The Review Name field accepts attribute transformers, so the name a review receives depends on the identity that triggered the workflow. Test the formatter from the action editor before saving the policy.

1. In the Review Name section of the Create Access Review action, select Test.

2. In Test Review Name Formatter, enter a sample value for each attribute the formatter references. Veza detects the attributes in the formatter and displays one input for each. Timestamp attributes accept ISO 8601 or RFC 3339 values, such as 2026-01-31 or 2026-01-31T09:15:32Z.

3. Select Test Formatter.

The generated name appears under Formatter Output. When the formatter produces more than one candidate value, the first four appear with an option to display the rest. If the formatter cannot be evaluated, the error replaces the output and Save stays disabled until you correct the formatter.

Selecting Save in the modal writes the edited formatter back to the action.

Veza evaluates the formatter on the server against the policy's current version, so results reflect the transformers and lookup tables that version defines. Conditional (IF) formatting is not available on this field.

1. A lifecycle event triggers a workflow containing the CREATE_ACCESS_REVIEW action

2. The action evaluates its settings against the identity that triggered the event

3. A review campaign is queued in Veza Access Reviews

4. The review campaign is created and assigned to the designated reviewers

CREATE_ACCESS_REVIEW generates two notification events:

You can configure email notifications or webhooks for both events to track review creation progress. See for configuration details.

Related Topics:

• : Behavior, filtering, entity matching, and troubleshooting

• : Configuring certification plans and managing reviews

• : Managing birthright entitlements included in reviews

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

Overview

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

Before you configure this feature, ensure you have:

• Administrator access to Veza Lifecycle Management settings

• An LCM-enabled integration that supports the action (such as Active Directory, Okta, or Snowflake)

• A policy with a Sync Identities action configured for the target integration (see and )

An account-only Access Profile grants access to an application without attaching any entitlement relationships. The account itself is created by the Sync Identities action in your policy; the account-only profile ensures no groups, roles, or permissions are added.

When an identity is assigned an account-only Access Profile:

1. The policy's Sync Identities action uses its Action Unique Identifier to check whether the identity already has an account in the target integration.

2. If no account exists and the action has Don't create new users unchecked, Veza creates a local account using the attribute transformers you configured.

3. No entitlement relationships are created. The account exists but has no group memberships, role assignments, or permissions.

The attributes written to the new account (such as username, email, and department) depend on the transformers configured in the Sync Identities action. See .

1. Open Access Profiles > Profile Types.

2. Click New Profile Type.

3. Enter the basic information:

   • Name: A descriptive name (for example, "Application Access Only").

For the full reference on profile type options, see .

After you create the profile type, create an Access Profile that provisions accounts to a specific integration:

1. Open Access Profiles > Profiles.

2. Click Create.

3. In Create Access Profile, choose your account-only profile type under Access Profile Type (for example, "Application Access Only"), then click Next.

For account provisioning to work, the policy that governs these identities must include a Sync Identities action for the target integration:

1. Open Lifecycle Management > Policies.

2. Edit the policy that governs the identities you want to provision.

3. In the workflow, confirm a Sync Identities action that:

   • Targets the same integration as your Access Profile

For details on configuring Sync Identities and attribute transformers, see and .

Assign identities to the account-only Access Profile through any of the standard methods:

• Birthright (policy workflows): Automatic assignment based on identity attributes and workflow conditions

• Access Requests: User-initiated requests with approval workflows

• Manual assignment: Direct assignment by an administrator

When an identity receives the profile, the policy's Sync Identities action creates the account (if it does not already exist) with the attributes mapped by your transformers, and no entitlement relationships are added.

This example creates Active Directory accounts with no group memberships.

Profile type:

• Name: "AD Account Only"

• Integrations: Limit to a single integration type → Active Directory

• Create local user/account only: Enabled

Sync Identities attribute mapping (configured in the policy). Map source identity attributes to the target Active Directory attributes:

• sAMAccountName ← {first_name}.{last_name}, with a fallback such as {first_name}.{last_name}{NEXT_NUMBER(1, 10)} to resolve duplicate usernames

• mail ← {email}

When an identity is assigned an Access Profile of this type, Veza creates an Active Directory user account with these attributes but does not add the user to any security groups. For conflict handling when a generated username already exists, see .

• - Full reference for profile type configuration

• - Creating and managing Access Profiles

• - Configuring automated workflows

• - The action that creates accounts

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:

Enforce password change on login

For Active Directory and Azure AD, the Reset Password action can force the user to change their password at next login. Google Workspace does not provide a Reset Password action. See the .

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 Payload action.

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.

Overview

System attributes are computed properties that Lifecycle Management automatically generates during identity processing. These attributes enable advanced automation scenarios by providing runtime information about identity changes and transformation results.

System attributes use two prefix conventions: sys_attr__ for computed boolean flags evaluated each extraction cycle (such as sys_attr__is_mover) and sys_attr_changed__ for per-property change detection attributes that are also re-evaluated each cycle. Neither can be manually set or modified.

Available System Attributes

sys_attr__is_mover

A boolean attribute that indicates whether an identity has undergone changes to monitored properties during the most recent extraction.

Type: Boolean Persistence: Transient (re-evaluated each extraction cycle) Available in: Workflow trigger conditions

Configuration: Define monitored properties in the policy configuration:

Workflow Trigger Example:

Combined Condition Example:

The attribute is re-evaluated on every extraction cycle. It is set to true when any property in mover_properties changes, and cleared otherwise. For identities that are unchanged in an extraction, it is explicitly removed from the stored identity record. It is excluded from change detection to prevent recursive updates.

A persistent boolean attribute that indicates whether an identity is new in Veza — either appearing for the first time, or returning after being removed from its source system.

Type: Boolean Persistence: Stored with identity record; cleared after the first extraction cycle where the identity appears Available in: Workflow trigger conditions

When this attribute is set:

• The identity has no prior record in Veza and appears for the first time in an extraction.

• The identity was previously removed from its source system (for example, a terminated employee) and has returned in a new extraction cycle. Veza treats this as a new identity so that joiner workflows fire for re-hires.

When this attribute is not set:

• The identity already has an existing active record in Veza from a prior extraction cycle, regardless of any attribute changes.

• The identity changed one or more properties but has a continuous record in Veza. Identities with attribute changes are indicated by sys_attr__is_mover or sys_attr_changed__<property>, not sys_attr__is_new_identity.

Trigger condition examples:

A transient attribute that provides a preview of the transformation result during conditional evaluation.

Type: String Persistence: Transient (exists only during IF statement evaluation) Available in: Conditional transformers only

Usage Example - Conditional Domain Addition:

The above transformer will check if the transformed email already contains "@", preserve existing email addresses, and add domain only when needed.

A transient attribute that provides the character length of the transformation result during conditional evaluation.

Type: Number Persistence: Transient (exists only during IF statement evaluation) Available in: Conditional transformers only

Usage Example - Progressive Username Truncation:

For "Leonevenkataramanathan Foster":

• First check (≤30 chars): leonevenkataramanathan.foster (30 chars - passes first condition)

• If >30 chars, second check (≤20 chars): leonevenkataramana.foster (25 chars - fails second condition)

• If >20 chars, fallback: l.f (3 chars - always succeeds)

Preview attributes work with the NEXT_NUMBER transformer for generating unique alternatives:

This evaluates the base value length before applying numbering, ensuring the final result (including numbers) meets constraints.

Only one NEXT_NUMBER transformer is allowed per conditional branch.

A family of dynamic boolean attributes that indicate which specific properties changed on an identity during the most recent extraction.

Type: Boolean Persistence: Transient (reset each extraction cycle) Available in: Workflow trigger conditions

How it works: When Veza processes an extraction event and detects that a property has changed since the previous extraction, it sets sys_attr_changed__<property_name> eq true on that identity's node. All sys_attr_changed__ attributes are cleared at the start of each extraction cycle, so they reflect only the changes in that extraction.

When this attribute is not present: If a property did not change in an extraction, its sys_attr_changed__ attribute is absent from the identity record — it is not set to false. This means the condition sys_attr_changed__department_name eq false will not match identities whose department did not change; it will simply not match at all. To trigger a workflow only when a property has not changed, omit the sys_attr_changed__ check and rely on the attribute value directly.

For new identities, Veza sets sys_attr_changed__<property> eq true for all properties, treating their first appearance as a change from non-existence.

Trigger condition examples:

Please note that sys_attr__is_mover is a persistent flag set when any property in the policy's mover_properties list changes. It does not identify which property changed. sys_attr_changed__ attributes are transient and per-property. They are set for all changed properties regardless of the mover_properties configuration.

Secondary entity attributes: For secondary entity nodes (such as an HRIS record attached to an identity), prefix the attribute name with the entity type followed by a period:

The entity type prefix matches the integration entity type name shown in the policy configuration. Without the prefix, the condition applies to the primary identity node.

The trigger condition editor autocompletes sys_attr_changed__ and then suggests available attribute names. After typing or selecting the prefix, enter the property name to complete the attribute.

• - Complete SCIM filter syntax for workflow conditions

• - Complete list of transformation functions

• - Attribute transformation concepts and examples

• - Configuring mover properties and workflows

Access Profiles govern how application entitlements are assigned to employees across your organization. These profiles define how birthright access should be granted based on segmentation criteria, such as business role, job function, seniority level, location, or group membership. Access Profiles are used by the Manage Relationship action to assign users to specific groups, roles, permission sets, or other access-granting entities when specific conditions are met.

Profiles can be configured hierarchically to create a fine-grained model for assigning access to different employee groups. Administrators can position child profiles beneath a parent profile, with each child profile inheriting the parent profile's entitlements.

For instance, a parent profile might be "Sales" (defining all the application entitlements that an individual belonging to the Sales organization should be granted), with child Profiles for "Account Executive," "Sales Engineering," "Sales Operations," and "Inside Sales." Each child Profile will have additional application entitlements specific to those roles. With these profiles configured, a workflow in policy for sales engineers can use just the "Sales Engineering" Profile, which includes the access defined by the "Sales" profile.

Example Profiles

Since workflows in Lifecycle Management policies can apply these Profiles at all stages in a user's lifecycle, defining Profiles enables Veza to serve as a source of truth for birthright entitlements for all employees. Access Profiles also define what access-granting relationships to remove from users during de-provisioning workflows.

The access granted by a Profile can be defined by both:

• Explicitly-defined, application-specific entitlements, such as roles, groups, permission sets, etc., within the Profile. A single Access Profile can support granting one or more entitlements across one or more applications simultaneously.

• Any entitlements inherited from a parent Profile.

The example below shows Business Roles for teams, managers, and all employees, along with Profiles for different applications. When configuring workflow actions, administrators can choose from one or more Business Profiles to assign the entitlements granted by the child Profiles.

Veza offers two types of built-in Access Profile types for defining birthright entitlements by user segments:

Profiles are a type of Access Profile used to define access-granting relationships (such as user assignments to groups or roles) within the applications you will provision to users. Profiles are intended to represent a specific set of entitlements across one or more applications that should be granted based on a user's segmentation criteria.

Profiles should be configured in coordination with the application owner, who will best understand the exact permissions and privileges granted by various groups, roles, and other entitlements in each specific application.

Business roles are a type of Access Profile used to model your organization's structure, based on a hierarchy of job functions, locations, and titles. Ideally, by itself, a Business Role should not describe specific entitlements but can inherit relationships from other Profiles. These will usually be named according to logical segments that should be assigned to different applications with different levels of access, such as "Sales," "QA Contractors," or "Engineering Managers."

Business Roles can inherit Profiles to enable a hierarchical approach to birthright access management. You should draft and review Access Profiles to create a map of user entitlements for each application (such as "GitHub Developers" or "Salesforce Administrators").

Create Business Roles that align with your organizational structure, especially considering location, business unit, and functional organization. Then, configure these Business Roles to inherit Profiles that describe the birthright entitlements granted to different user populations.

To create and manage Access Profiles, go to Access Profiles > Profiles.

1. Click Create.

2. In the Create Access Profile dialog, choose the Access Profile Type to create, then click Next:

   1. Business Role: Business roles are intended to represent logical units within your organizational structure, and can inherit entitlements defined in other Access Profiles. Use Business Roles to establish segmentation criteria based on location, role, business unit, or functional organization.

After saving an Access Profile, you can view its details, edit it, or pause and resume it on the Access Profiles > Profiles page.

When configuring a policy to include the Manage Relationships action, you can select any active profile for the target data source. You can also use Dynamic Access Profiles to resolve Access Profile names at runtime based on user attributes. See for details.

Access Profiles can have designated owners who are responsible for managing and maintaining the profile. Owners have elevated permissions to configure the profile, manage its lifecycle, and create additional profiles.

Both Veza Users and Veza Groups can be assigned as Access Profile owners:

• Individual Users: Any Veza platform user with the appropriate permissions

• Veza Groups: Both Customer Managed groups (created in Veza) and SCIM Managed groups (provisioned from identity providers). See for details on group types and management

To be eligible as an Access Profile owner, a user or group must have the Creator permission set for the relevant Access Profile Type. This is a two-step configuration process:

1. Grant Profile Type Permissions:

   • Navigate to Access Profiles > Profile Types

   • Locate the profile type in the table

   • Click the Actions button (⋮) for that profile type

When a user or group is designated as an Access Profile owner, they automatically receive three distinct permissions:

1. Owner permission on the specific Access Profile

   • Read: View the profile's configuration, entitlements, and metadata

   • Update: Modify the profile's settings, labels, descriptions, and assigned relationships

   • Create

These permissions enable owners to not only manage their assigned profiles but also create additional profiles of any type they have access to.

Access Profile owners are managed through the Access Profiles interface:

1. Navigate to Access Profiles > Profiles.

2. Locate the Access Profile in the list.

3. Click the Actions button (⋮) for that profile.

4. Select Manage Owners from the dropdown menu.

Custom Attributes are admin-defined metadata fields that can be set on individual Access Profiles. You can use them to tag profiles with organizational context such as cost center, team, compliance classification, or region.

These custom property values are available as parameters during dynamic approval rule evaluation, and support Access Requests approval routing driven by profile metadata. For example, this can enable tagging Access Profiles with a specific cost center and routing them to the appropriate approver group. See for configuration details.

Before custom properties can be set on individual profiles, an administrator must define the allowed attributes:

1. Navigate to Access Profiles > Profiles.

2. Click Settings in the page header.

3. In the settings sidebar, select Custom Attribute Definitions.

4. Add one or more attribute definitions. For each attribute, specify:

Custom attribute schemas are applied across all Access Profiles in the tenant. Definitions cannot be set on individual profile types.

Once schemas are defined, a Custom Properties section appears when creating or editing any Access Profile:

1. In the Access Profile create or edit form, scroll to the Custom Properties section.

2. Click Add Custom Property.

3. In the dialog, select the Property (attribute name) and enter or select an Attribute Value.

To edit custom properties for an existing profile, select it from the Profiles list to view details. In the header, locate the Custom Properties section and click to add or remove properties.

Custom property values are validated against the current definitions. Property names must match a defined attribute, and values must come from the predefined list when one is configured.

Custom property values are included in the API response when retrieving or listing Access Profiles via the custom_properties field (private API).

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:

• Policies: Displays your most recently updated Lifecycle Management Policies and their status

• Access Profiles: Shows configured 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 the "Create Policy" button in the 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 Policies section displays all configured Lifecycle Management policies with their current status. Each policy shows its name, associated identity source, number of identities managed, and current status (Running/Stopped).

You can view all policies at a glance, create new ones with the "Create Policy" button, see which policies are actively running, access detailed configuration by clicking on 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:

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.

The IAM challenge

Without automated lifecycle management, organizations face a fragmented identity and access management landscape. Multiple systems require manual coordination, leading to delays in provisioning, security gaps from orphaned accounts, and compliance risks.

How Veza streamlines IAM

Veza Lifecycle Management provides a unified platform that automates identity provisioning and de-provisioning across your entire technology stack. Changes in your HR system automatically trigger coordinated workflows across all connected applications, ensuring consistent access management throughout the employee lifecycle.

Before you begin creating draft Policies for automating Lifecycle Management workflows, you should establish and document how employees in your organization are mapped to business roles, and corresponding birthright entitlements (default access permissions granted based on an employee's role) such as groups and roles in target applications.

Implementing Veza Lifecycle Management will require:

• Defining segmentation criteria in terms of Business Roles for identities in your organization.

• Defining Role Conditions used in Lifecycle Management policies that Veza will use to match roles to identities, based on attributes from the source of identity.

• Defining Profiles for each target application that will map Business Roles to application-specific entitlements.

• Assigning Profiles to Business Roles to enable business rules.

The topics in this document will help you structure your Lifecycle Management implementation, and establish foundations that you can use to simplify access management throughout the employee lifecycle.

• Is a lifecycle management process defined for your organization?

  • If yes: Begin assessing your current policies for implementation with Veza Lifecycle Management.

  • If no: Work with application owners, HR administrators, and other stakeholders to establish protocols for granting and revoking access as employees join, depart, or change roles.

• Do you have one, or even multiple sources of truth for employee identity metadata?

Implementing Lifecycle Management requires careful attention to access control, API key management, and credential handling to maintain security throughout your deployment.

Access control

Limit administrative access: Reduce standing administrator roles to those who need them. Best practice is no more than 5 administrators with standing access.

Use operator role for monitoring: Users with Operator roles can view LCM policies without editing them. Use this role for monitoring and troubleshooting.

Temporary support access: When working with Veza support on LCM issues, grant temporary administrator privileges using Administration > Support User Access rather than creating permanent accounts.

API key management

Monitor Veza API keys and disable unauthorized keys. API calls made with keys that have administrator privileges can modify LCM policies.

Key rotation best practices:

• Review API keys quarterly

• Revoke keys that are no longer in use

• Document the purpose of each active key

• Use separate keys for different automation purposes

Integration credentials

Credential lifecycle:

• Track credential expiration dates and renew before expiry

• Avoid editing integration credentials except when renewing them

• Test credential changes in a sandbox environment before applying to production

Critical system protection: Identity source extractions are the most critical step in the LCM process. Handle integration configuration changes with care:

• Schedule credential updates during maintenance windows

• Verify extraction success immediately after credential changes

• Have rollback procedures ready if extraction fails

Begin by identifying and cataloging the different roles that can be assigned to employees and their digital identities within your organization. Users will be granted entitlements within target applications based on these business roles based on your Lifecycle Management .

This list of business roles might be sourced from an organization chart, or a human resources information system (HRIS). These roles can be defined in terms of any discriminating attributes from a source of identity, such as:

1. Employee or contractor status

2. Roles and job positions

3. Business Units (BUs)

4. Locations

Example Business Roles:

• Sales

• Developers

• Executive Employees

• US Employees

Identify the attributes and conditions that will identify the segment each user belongs to. The possible attributes will depend on the employee metadata provided by your HRIS or other source of truth for identity.

For example, you might assign certain Active Directory groups only to US employees, identified by a source Workday Worker's work_location. To define these conditions, you will need to understand what attributes are available within the source of truth, and how the values map to each employee segment.

1. Consider how employee records are structured in your source of identity, including all the built-in attributes belonging to an identity, and the possible values.

2. Check if any custom attributes can be used to define role conditions, and ensure these are enabled in the Veza Access Graph.

3. Document how employee populations correspond to the attribute values contained in the source of identity.

Examples: Source attributes for role conditions

The following standard attributes are available by all HRIS integrations that use an Open Authorization API template, along with any enabled for the integration. You can typically import data from any HRIS system to Veza using this template, sourced from a generated report, API calls, or CSV data.

Using this standard identity metadata, a Lifecycle Management workflow runs specific actions for identities where some or all of the conditions are true:

• Employment Status equals "Pending"

• Employment Types equals "Full Time"

• Department equals "Engineering"

• Work Location equals "US"

A Profile defines a set of entitlements for a specific application that can be assigned to users. For each target application, application owners will need to establish levels of birthright entitlements by defining Profiles mapped to groups, roles, or other entitlements that can be assigned to a user.

1. Review target applications to validate that the expected entitlements are configured, with the correct scopes and permissions for the Profiles they will be associated with.

2. Create Lifecycle Management mapped to those entitlements.

Examples: Access Profiles

When configuring the action, administrators can grant or revoke access by choosing a Business Role that inherits the desired Profile.

Configure to inherit the corresponding access profiles, mapping entitlements to employee segments.

1. Create Business Roles for each segment.

2. For each Business Role, inherit a corresponding access profile.

3. Assign one or more Profiles to each Business Role as needed to fully define the birthright entitlements for each position.

Examples: Map Business Roles to Profiles

Asia Employees

US Employees

Developers

Attributes from the source of identity can determine the attributes of users in target systems when creating or updating a target entity.

For example, a provisioned Okta User's country_code might be set to a source Workday Worker's work_location. Additionally, the Okta User manager attribute could be continually synchronized to match the Worker’s manager.

Target synced attributes can have fixed values (e.g., always true), can match a source attribute, or contain a combination of source values, transformed as needed to match the required format. Rules for synchronizing attributes are managed with .

1. For each application, understand the supported attributes for provisioned users.

2. Assess the identity metadata from your source of truth to decide how source entity attributes will be used to set the values of target entity attributes.

3. Veza can synchronize attributes during provisioning and de-provisioning workflows, and whenever a change is detected in the source of identity. Decide which attributes should be kept in Continuous Sync, and which should only be created (and never modified after creating an entity).

Examples: Synced Attributes

Sync Active Directory Accounts for Active Employees (Joiners/Movers)

When provisioning AD Users, create user attributes based on values in the source of identity. These attributes can also be kept up-to-date with the source of identity when there are changes, by enabling Continuous Sync.

Sync Active Directory Attributes for Withdrawn Employees (Leavers)

When disabling AD Users, update the DN and Primary Group DN to a group and OU reserved for terminated employees:

• Moving leavers into a "Terminated Users" group (via the primary_group_dn attribute) effectively restricts access to systems that rely on Active Directory for authentication and authorization.

• Updating the distinguished_name to place leavers in a specific organizational unit (OU), like "Evergreen Termination," separates active users from inactive ones, and enables the application of policies, scripts, and queries that target inactive users without affecting active employees.

Overview

When connecting to integrated systems (see Veza Integrations), Veza ingests properties from the source systems (e.g., Workday, Okta, Active Directory) and normalizes them into standardized attributes that appear when configuring Workflow trigger conditions, configuring Actions, and in Identities views.

While these standardized attributes are intended to ensure consistent naming across different systems, it is important to understand that some attributes may appear differently than their original names in the source system.

You can retrieve the original attribute names for enabled Lifecycle Management integrations using the ListLifecycleManagerDatasources API.

Attribute Naming Conventions

Veza normalizes all property names for consistency:

The following normalization rules typically apply:

• Source properties are converted to lowercase

• Any spaces and hyphens become underscores

• Special characters removed

• CamelCase converted to snake_case

The following sections include some examples of how Veza handles attributes from common integrations.

Veza recognizes and standardizes many common attributes across source systems:

Veza will make conversions to some attribute names from the source integration. For example, sAMAccountName in Microsoft Active Directory is shown as account_name for Active Directory Users in Veza Access Graph.

Workday → Veza

Okta → Veza

Active Directory → Veza

Some integrations support custom property extraction for organization-specific fields from custom reports or extended schemas:

• Always prefixed with customprop_

• Automatically discovered during extraction once enabled

• Follow standard normalization rules (lowercase, underscores)

Examples:

• customprop_department_code - Custom department identifier

• customprop_employeeou - Organizational unit

• customprop_region - Geographic region

Some entity attributes are computed by Veza, and not derived from source data:

• sys_attr__is_mover - Identity has changed monitored properties

• sys_attr__would_be_value - Preview value in conditional transformers

• sys_attr__would_be_value_len - Preview value length in conditional transformers

See for details.

When configuring a Workflow trigger condition or an action that syncs attributes, you can choose from available attributes using a dropdown menu.

Primary Source - Attributes from the main identity source appear without prefixes:

Secondary Sources - Attributes from additional sources are prefixed with the entity type:

Lifecycle Management uses two different expression syntaxes depending on the context:

In Workflow Conditions (SCIM Filter Syntax):

Trigger conditions use SCIM filter syntax to evaluate boolean expressions. See for complete documentation.

In Transformers (Formatter/Pipeline Syntax):

Attribute transformers use curly braces and pipes to produce output values. See for complete documentation.

With Secondary Sources (in Conditions):

• - Computed attributes for advanced scenarios

• - Modifying and combining attribute values

• - Using attributes in workflow conditions

Overview

You can use Lookup transformers to convert identity attributes from a source system into appropriate values for target systems based on CSV reference tables. This is particularly useful when mapping values between systems that use different naming conventions, codes, or formats for the same conceptual data.

For example, you might need to transform a "Location" attribute from Workday (which might be stored as location codes like "MN001") into corresponding values for country, country code, or city names in a target system.

Use Table Lookup Transformers when:

• You need to map source attribute values to different values in target systems

• You have standardized reference data that must be consistent across applications

• You need to extract different pieces of information from a single attribute value

• You have complex mapping requirements that built-in transformers cannot support

1. Geographic Information:

   • Transform location codes to country, region, city, or time zone information

   • Map office codes to physical addresses or facility types

2. Organizational Mapping:

The Table Lookup Transformer references CSV-based mappings between source and destination values. When synchronizing user attributes, Veza:

1. Takes the source attribute value

2. Looks up this value in the specified lookup table

3. Returns the corresponding value from the designated return column

4. Applies this value to the target attribute

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

For example, a location mapping table might look like:

To create a new lookup table:

1. Open a draft version of your policy (you can only add lookup tables to a draft) and select the Workflow Components tab

2. Select the Lookup Tables card

3. Click + on the card. When the policy has no lookup tables yet, you can also click Create Lookup Table

4. Provide a Name

From the Lookup Tables card, you can:

• Export the table's CSV

• Edit the table's name, description, or CSV. Renaming a table also updates the formatters that reference it by its old name

• Delete tables that are no longer needed. Delete is unavailable while an action, workflow, condition, transformer, or transformer function still references the table

To update an existing lookup table:

1. Create a new policy draft version.

2. Delete the CSV from the existing lookup table (do not delete the table itself).

3. Upload the updated CSV.

4. Publish the draft.

To use a Table Lookup Transformer in a common or action-synced attribute:

1. In Destination Attribute, choose the attribute on the target entity that will be updated

2. In Formatter, choose the source attribute to transform

3. In Then Apply, enter the lookup function: the lookup table name, the column to match against, the column containing values to return, and (optionally) a default value to return when no match is found.

Then Apply holds the function chain on its own, with no braces and starting with a pipe, for example | LOOKUP, "locationTable", "location_code", "city". Veza applies it to the value that Formatter produces.

The equivalent complete expression, used wherever a single field carries both the source value and its transformations, is:

Where:

• <value> is the source attribute to transform (for example, location)

• <table_name> is the name (or ID) of the lookup table to use

• <column_name> is the column in the table to match against

Separate the function name from its parameters with a comma, and enclose each parameter in double quotes, as shown above. Veza matches the table name and both column names exactly, including case.

Assuming a user has "location": "CA001" and a lookup table named locationTable structured as shown earlier:

You can combine lookup transformations with other transformation functions in a pipeline:

This would look up the state_code corresponding to the location value and convert it to lowercase.

By default, when a source value is not found in the lookup table, the transformation fails for that attribute. To return a fallback value instead of failing, supply an optional fourth parameter that sets a default value:

When the source value is not found in the table, the transformer returns the default value (Unknown location in this example) instead of failing. To return an empty string on a miss, pass an empty default ("").

The default value applies only when the lookup runs but finds no matching row. It does not cover configuration errors: if the lookup table, the match column, or the return column cannot be found, the transformation still fails, even when a default value is provided.

For full coverage, ensure your lookup table includes entries for all possible source values that may be encountered during provisioning, or supply a default value to handle unmatched inputs.

To ensure robust provisioning workflows, include all expected values in your lookup table, validate source data before implementing lookup transformations, and test transformations with representative data sets.

• Lookup tables are immutable and automatically deleted when no longer referenced by any policy version

• Multiple policy versions can reference the same lookup table (for example, an active version and a draft version)

• Lookup tables are defined at the policy level and can be referenced by any transformer within the policy

• Lookup tables can have multiple columns to support different transformations from the same reference data

1. Standardize Naming: A lookup-based transformer references the table by the Name you gave it when you created it (or by its table ID), not by the CSV file name. Apply consistent conventions for both the table and columns.

2. Document Mappings: Add descriptions for each lookup table to explain its purpose

3. Validate Data: Ensure lookup tables are complete and accurate before using them in transformers. Consider how lookup tables will be maintained over time, especially for values expected to change.

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

• 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

Creates email accounts for identities through integrated email providers. This action is typically used in onboarding workflows alongside Sync Identities 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. Sync Identities 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 Sync Identities action, targeting Active Directory and mapping only

See the in the Actions overview for a complete workflow.

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

• Dynamically assign access based on user attributes (department, location, role)

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

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:

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

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

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

• Set for new users only - The attribute value is set only when creating new user accounts

• Set for new and existing users - 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 off Update only on create or reactivate on the Sync Identities action

2. Select Set for new and existing users for the department attribute

Set for new and existing users (continuously sync attributes that change during employment):

• Given Name, Surname

• Department

• Title

• Manager

Set for new users only (preserve stable identifiers):

• Active Directory sAMAccountName

• Email Addresses (for Email Write-Back action)

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

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

• Contractor account removal after project completion

Supported Integrations:

• Active Directory (Users and Managed Service Accounts)

• Okta

• Azure AD (Users)

• Google Cloud (Google Workspace Users)

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

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

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.

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

• Define the overall automation framework for managing identities throughout their lifecycle

• Specify which source of identity triggers the automation

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:

• Validate that workflow trigger conditions match the intended identities

• Preview what provisioning or deprovisioning actions would occur