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 .

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

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.

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

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

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

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

Example Use Cases:

• Create new user accounts in target systems when employees join

• Update user attributes when information changes in HR systems

• Ensure consistent user information across multiple platforms

Password output (Early Access)

When password output is enabled, the password generated during identity creation is available to subsequent workflow actions via transformer expressions. Use {EntityType.password} syntax to reference it, such as {OktaUser.password} in a Send REST Request payload.

This is useful in joiner workflows where Veza provisions a new account and needs to pass the generated password to a downstream system such as an HR portal or ticketing API.

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 all methods. The available methods are determined by the integration's DeProvisionIdentityDefinition and are shown in the action configuration dropdown.

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

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 (e.g., Workday) with the newly created email address

See the in the Actions overview for a complete workflow.

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

• Create a service desk ticket for any manual steps

• Send standardized notifications using custom templates across workflows

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

• Default template: Uses the built-in event-specific template based on the lifecycle event being processed

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

Custom templates support the same placeholders as event-specific templates, enabling dynamic content like identity names, workflow names, and action results. See for placeholder reference and template management.

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:

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 .

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.

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)

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

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:

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

Access Profile Types determine the behavior of Access Profiles for Veza Lifecycle Management and Veza Access Requests. They define common characteristics such as:

• Whether the profile can inherit entitlements from other profiles

• If the profile can grant entitlements in one or more target applications

• The maximum number of entitlements the profile can grant

• The specific integrations where entitlements can be granted

Veza provides built-in profile types, such as Profiles and Business Roles, for hierarchical management of birthright entitlements by employee population. You can also create new profile types to meet your organization's Access Requests and Lifecycle Management needs.

Access Profiles define collections of entitlements within one or more target applications that can be assigned to an identity. Depending on the profile type, an access profile can include certain groups or roles, or inherit entitlements from another profile.

For example, you can create different types to organize profiles by:

• Applications: Granting access to an application without specific entitlements, such as access to Zoom, a video conference platform

• Single Entitlements: Defining a single entitlement within a single application, such as a user being added to the DNS Admin group in Active Directory or the Domain Name Administrator role in Entra ID

• Application Entitlements: Defining multiple entitlements within a single application, such as access to several Okta Groups

Use Access Profile Types to set rules for all profiles using that type. You can create new profile types to implement Lifecycle Management and Access Requests based on the access you grant to employees and the conditions under which it is granted.

1. Open Lifecycle Management > Settings.

2. In the Profile Types section, click New Profile Type.

3. In the sidebar, configure the new type:

After saving a profile type, you can edit or delete it on the Lifecycle Management Settings > Profile Types tab.

• To manage the users or groups allowed to create profiles of that type, click Actions > Manage Permissions.

• To view profiles with a specific type, choose a profile type and click Show Access Profiles.

The Manage Permissions option controls who is eligible to be designated as owners of Access Profiles of a specific type. When you assign the Creator permission set to a user or group for a profile type:

• They become eligible to be designated as owners of Access Profiles of that specific type

• Once they become an owner of any profile, they automatically receive global Creator permission to create Access Profiles of any type

• If a group receives Creator permissions, all group members inherit these capabilities (see for details on group management)

This permission configuration is required to assign Access Profile ownership. See for details on designating owners for individual profiles.

When working with Access Profile Types, consider the following best practices:

• Consistent Naming: Use clear, descriptive names for profile types that indicate their purpose and scope

• Appropriate Granularity: Create profile types with the right level of granularity for your organization's needs

• Documentation: Add thorough descriptions and instructions to help others understand when to use each profile type

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.

How it works

When an access request is submitted, Veza evaluates any policy steps configured with a Dynamic Approver:

1. Veza considers the name of the Access Profile or Catalog Definition being requested, and any custom properties set on that profile.

2. Each transformer step in the Dynamic Approver pipeline runs in sequence, processing the available attributes to produce an intermediate or final output.

3. The final transformer step must output one or more approver email addresses.

4. Veza assigns those email addresses as approvers for that policy step.

The following attributes are available as inputs to transformer expressions:

Custom property attributes (access_profile_properties.* and catalog_definition_properties.*) are populated from the custom attribute definitions configured in . The attribute names available in the transformer editor reflect the definitions currently configured in your tenant.

Transformer expressions use the same syntax as Lifecycle Management : {attribute} for a direct reference, or {attribute | FUNCTION, arguments} to apply a function.

The most common function for Dynamic Approvers is LOOKUP, which resolves a value by looking it up in a . Lookup tables are CSV-based reference tables that map values between systems — for example, mapping department codes to approver email addresses. They are uploaded and managed within Lifecycle Management policy configurations.

The LOOKUP syntax is: {value | LOOKUP, "table_name", "match_column", "return_column"}

For example:

This takes the department custom property value from the Access Profile, looks it up in the dept_approvers lookup table by matching the dept_code column, and returns the corresponding approver_email value. See for details on creating and managing lookup tables.

You can chain multiple transformer steps. Use {last_output} in a subsequent step to reference the output of the previous step.

1. Go to Lifecycle Management > Settings.

2. Select the Access Request Settings tab.

3. Scroll to the Dynamic Approvers section and click Create Approver.

This example resolves a department code to approver usernames via a lookup table, then appends a domain to produce email addresses.

Step 1 — Look up approver usernames from department code

Output Type: String List

Step 2 — Convert usernames to email addresses

Output Type: String

Before linking a Dynamic Approver to a policy, use the built-in test configuration to verify it resolves to the expected approver emails.

1. In the Create or Edit Dynamic Approver dialog, scroll to Test Configuration.

2. Under Test Source, select Access Profile or Catalog Definition, then choose a specific record to test with.

3. Optionally, add Policy Properties — key-value pairs that simulate additional request context during testing.

If the test returns no results or an unexpected value, check that the referenced lookup table is populated, the custom property values are set on the selected profile, and the attribute names match your definitions.

Once a Dynamic Approver is configured, link it to an approval step in an Access Request Policy:

1. Go to Lifecycle Management > Settings > Access Request Policies.

2. Create or edit a policy.

3. Under Approver Settings, add or edit an approval step.

When an access request matches this policy, Veza runs the selected Dynamic Approver pipeline at request time to determine the approver(s) for that step.

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

• Trigger key rotation after a security incident

Supported Integrations:

The Veza app registration must have the rotate operation on the target Key Vault. The List permission used for extraction is not sufficient. Grant the rotation permission using the model the vault uses:

• RBAC model (recommended): Assign the Key Vault Crypto Officer role to the Veza app registration on the target vault. This role includes the keys/rotate permission.

• Access policy model (legacy): Under Key Permissions, add Rotate, Get Rotation Policy, and Set Rotation Policy.

Microsoft recommends RBAC over access policies for new vault deployments. See and the .

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:

• Create new users - When enabled, the action will create new user accounts that don't exist in the target system

• Update active users - When enabled, the action can update existing user accounts with attribute changes from the source of truth

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. Enable Update active users on the Sync Identity 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):

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

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

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

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, toggle the Enabled control back to enabled and save.

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.

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

• Incorrect or slow-to-update attributes:

The Lifecycle Management Activity Log provides visibility into all provisioning operations performed by Veza's Lifecycle Management system. It serves as a record of all activities, including successful actions, errors, and failures.

Overview

A Lifecycle Management policy defines automated workflows that execute when changes occur in a source of identity. The Activity Log tracks all aspects of these operations through a hierarchical structure:

1. Policies define the overall automation framework for managing identities

2. Workflows determine which actions should be executed for specific identities

3. Actions represent specific operations to be performed on target systems

4. Jobs are individual tasks executed as part of actions

5. Events record atomic changes resulting from successful jobs

The Activity Log provides four views of this activity across different tabs: Events, Jobs, Actions, and Workflow Tasks.

Each tab can help 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 implementation.

The Events tab shows individual changes made to entities and relationships within the system. Each event represents an atomic change resulting from a successful action.

The Jobs tab displays individual jobs executed as part of actions. Jobs represent specific tasks performed on target systems, such as creating a user account or updating attributes. Use this tab to review whether individual jobs executed successfully or encountered an error and could not be completed.

The Actions tab shows high-level operations triggered by workflows. Actions typically involve one or more jobs that work together to accomplish a specific goal.

See for more details on supported actions and configuration options.

The Workflow Tasks tab displays workflows executed for specific identities. Workflows represent a sequence of actions executed as part of a Lifecycle Management .

For each identity, Lifecycle Management follows this process:

1. Validation: The system validates the identity against workflow trigger conditions

2. Execution Determination: The system determines whether execution is needed based on:

   • Identity state (e.g., CREATED, CHANGED, UNCHANGED)

The Activity Log provides filtering and search options to help locate particular events:

• Filter by time period: Use the date range filters to focus on date ranges

• Search by identity or entity: Use the search fields to find activities related to unique identities or entities

• Filter by event type or state: Use the dropdown filters to focus on event type or state

Veza maintains all Lifecycle Management activity logs for audit purposes. These logs are retained even if the associated integration is removed, maintaining a full historical record of all provisioning operations.

Note: Events shown in the Activity Log are distinct from the system-wide Event Logs found in the Veza Administration section.

Review the Activity Log after extractions complete to verify expected workflow execution. For large policies, trigger evaluation and workflow execution can take several minutes to complete. Allow time for processing before reviewing activity.

For advanced monitoring requirements, you can build custom dashboards using Veza's query and dashboard features to track LCM policy health metrics. Contact for guidance on building LCM-specific monitoring dashboards for your deployment.

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.

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

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:

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.

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

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

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

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

Overview

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.

Before you start

• You have the Administrator role on the root team

• Access Controls are enabled on your tenant (contact Veza support)

• The users receiving permissions have the Operator role assigned

To assign Access Profile creation permissions to users or groups:

1. Navigate to Lifecycle Management in the navigation sidebar.

2. Click Settings in the Lifecycle Management sidebar.

3. On the Settings page, locate the Access Profile Types section.

Result: Users and groups with Creator permissions can now create new Access Profiles from the Lifecycle Management > Access Profiles page.

To confirm that permissions were assigned correctly:

1. In the Manage Permissions modal, review the list of assigned users and groups.

   Each row shows:

   • Principal name (user or group)

   • Principal type (User or Group)

To revoke Access Profile creation permissions:

1. Navigate to Lifecycle Management > Settings.

2. Click Manage Access Profile Creation Permissions.

3. In the permissions table, locate the user or group to remove.

Result: The user or group can no longer create new Access Profiles. They retain read-only access to view existing profiles.

• - Overview of the permission sets system

• - Understanding Access Profiles and their role in Lifecycle Management

• - Veza role definitions and capabilities

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

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

These terms are used throughout Lifecycle Management documentation.

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

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

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

Use LCM-triggered access reviews to:

• Automatically certify access when employees change roles (movers)

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.

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.

When provisioning new identities through Lifecycle Management, unique attributes like usernames, login IDs, or email addresses must not conflict with existing values. Fallback formatters provide an automated way to generate alternative values when conflicts arise, ensuring provisioning can proceed without manual intervention.

You can configure fallback formatters when configuring a to ensure new users can be onboarded efficiently, regardless of naming conflicts.

The most common use case for fallback formatters is handling username conflicts. For example:

Your organization uses a standard username format of first initial + last name (e.g., jsmith for John Smith).

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 timezone information

   • Map office codes to physical addresses or facility types

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. Navigate to the Lookup Tables tab within your policy configuration

2. Click Edit mode to enable policy changes

3. Click Add New to create a new lookup table

From the Lookup Tables tab, you can:

• Edit table descriptions or upload a new CSV

• Delete tables that are no longer needed

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, specify the lookup table name, the column to match against, and the column containing values to return.

The full syntax for using lookup table transformers is:

Where:

• <value> is the source attribute to transform (e.g., {location})

• <table_name> is the name of the lookup table to use

• <column_name>

Assuming a user has "location": "IL001" 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.

When a lookup value is not found in the table, the transformation will fail for that specific attribute.

For full coverage, ensure your lookup table includes entries for all possible source values that may be encountered during provisioning.

To ensure robust provisioning workflows, it's important to 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 (e.g., 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

1. Standardize Naming: To use a lookup-based transformer, you will reference the table by 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.

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.

System attribute names are case-sensitive and must be lowercase in all expressions.

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

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:

• Validate that workflow trigger conditions match the intended identities

• Preview what provisioning or deprovisioning actions would occur

• Test policy changes safely before deployment

• Troubleshoot when workflows are not triggering as expected

Before testing with dry run:

• Create or edit a Lifecycle Management policy with at least one workflow

• Ensure your source of identity contains test identities or representative data

Use single-identity dry run to test how a specific identity would be processed by a policy.

1. Go to Lifecycle Management > Policies.

2. Select a policy to view its details.

3. Click Perform Dry Run.

1. Go to Lifecycle Management > Identities.

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

3. Click the Actions menu and select Policy Dry Run.

Use bulk dry run to test a policy against multiple identities at once. You can test against all identities or filter to a specific subset.

1. Go to Lifecycle Management > Policies.

2. Select a policy and click Perform Dry Run Bulk.

3. Choose your identity selection method:

Dry run results show what would happen if the policy ran against the selected identities.

The Workflows Run section shows which workflows triggered for the identity and why. If no workflows matched, verify that the identity's attributes meet the workflow trigger conditions.

The Potential Changes section lists all actions that would run, including:

• User accounts that would be created or updated

• Attributes that would be synced

• Access profiles that would be assigned or removed

• Relationships (group memberships) that would be added or removed

Click View Details on any action to see its full configuration, including sync attributes, relationship mappings, REST payload contents, and password complexity rules.

When a dry run returns "0 changes", the selected identity does not meet any trigger conditions in the policy's workflows. This is not an error; it means the identity would not be processed by this policy.

When running a bulk dry run, you can filter results to focus on identities where the policy would actually change attribute values. This helps you identify accounts that are out of sync with your policy's desired state, without manually reviewing every identity.

In the bulk dry run results table, use the Has Attribute Changes filter dropdown in the filter bar above the results to show only identities where one or more attributes would be modified. The results table shows which attributes would change for each identity. When multiple attributes would change, they appear as tags and collapse to Attribute Changes (N) when there are many.

For each attribute that would change, the dry run captures three values:

• Current Value: The attribute value that Veza last synced to the target system

• Current Graph Value: The value currently observed in the target system (which may have drifted from the last sync)

• New Value: The value the policy would write on the next run

Reviewing these three values together helps you understand whether a difference is due to configuration drift, a manual change in the target system, or a policy update — and whether the proposed change is expected.

Bulk dry run results are preserved in a history table, so you can review previous tests and compare results across multiple runs.

1. Go to Lifecycle Management > Policies.

2. Select a policy.

3. Click See Dry Run Bulk History.

The history shows each dry run task with its filter criteria, identity counts, workflow matches, and timestamps.

Disabled workflows are evaluated by default during dry run simulations. This means you can test workflow logic before enabling it in production. The dry run results show what actions would run if the workflow were enabled.

To learn how to disable workflows, see .

Dry run has several important limitations:

Dry runs validate trigger and condition matching but do not evaluate:

• "First time only" workflow flags (the flag that prevents re-triggering)

• Property change detection (for sync workflows)

• Scheduled triggers

• "Skip if action has already been run" action flags

These behaviors only execute in live policy runs. Test these scenarios with individual identities in a controlled environment before full deployment.

• No integration testing: Dry run does not check whether integrations are functioning properly or whether target systems are accessible. A broken integration might cause workflow-defined changes not to be applied when the policy runs.

• No action validation: Dry run evaluates whether workflow conditions are met, not whether actions would succeed. It does not validate that changes could be successfully applied.

• Simulation only: Dry run identifies actions that would execute but does not perform them.