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

Core Concepts

Policies

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

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

Learn more about Policies

Workflows

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

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

Learn more about Workflows

Access Profiles

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

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

Learn more about Access Profiles

Actions

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

Learn more about available Actions

Attribute Transformers

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

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

Learn about Transformers

Notification Templates

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 Notification Templates

Getting Started

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

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

3. Create Policies: Add policies to automate identity management processes. Building Lifecycle Management Policies

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

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

For API documentation, see Lifecycle Management APIs.

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 Access Profiles and usage metrics

• Identities: Provides a visualization of managed identities

• Integrations: Top Integrations 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 Events

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.

Dashboard Actions

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

• Track recent changes: Review the Recent Activity section for a log of recent events

• Filter activity by time period: Use the time period dropdown (e.g., "Past day") to adjust the view

Policies

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 creating and managing policies.

Access Profiles

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 Configuring Access Profiles.

Identities

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.

Integrations

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 Lifecycle Management integrations for more information.

Access Requests

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.

Errors

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.

Recent Activity

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.

Next Steps

After familiarizing yourself with the dashboard:

• Learn about creating Lifecycle Management policies

• Configure access profiles for your organization

• Set up integrations with identity sources

• Understand available Lifecycle Management actions

Overview

Access Profile Types determine the behavior of 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.

Common Access Profile Type Categories

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

• 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

• Multi-Application Entitlements: Defining multiple entitlements across different applications, such as for site reliability engineers who need access to GitHub, AWS, Jira, and Snowflake, along with one or more roles and group memberships within each of those applications

• Business Roles: Inheriting combinations of other profile types to model sophisticated access privileges, such as all US Call Center employees inheriting US Employee access

Managing Access Profile Types

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 how and what access you will grant to employees.

Creating a New Profile Type

1. Open Lifecycle Management > Settings

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

3. In the sidebar, configure the new type:

   • Basic Information shown when creating Access Profiles:

     • Name: Display name for the profile type, shown when creating new Access Profiles

     • Description: Extended description to document the purpose of the profile type

     • Instructions: Optional custom instructions for using the profile type, shown when creating new profiles. Note that this is useful if allowing self-service Access Profile creation.

   • On Create Behavior: Set the default policy state for Access Profiles created with this profile type:

     • Default: Uses Veza's default behavior (currently sets the profile to Initial state, but this may change in future releases)

     • Initial: The Access Profile is created but remains inactive/non-functional until a user explicitly starts it to move it to Running state

     • Running: The Access Profile starts in an active state and is immediately functional with no additional action required

     • Initial Start By Admin: The Access Profile starts in Initial state but requires an administrator (not a regular user) to explicitly start it to move it to Running state

   • Relationship Options:

     • Allow Inheritance from Other Access Profiles: When enabled, profiles with this type can use another access profile to specify the exact entitlements.

     • Allow Direct Relationships: When enabled, you will specify the exact entitlements when creating a profile with this type. When disabled, profiles with this type can only inherit entitlements from another profile

   • Access Request Policy: Choose the default Access Request Policy to apply access duration controls and approval workflow.

     • Allow overwrite of Access Request Policy: Enable selection of an alternative policy when Access Profile creators and owners create Access Profiles of this type.

   • Integrations: Choose if the Access Profile of this type supports multiple integrations, integrations of a single type, or a single instance of a single integration:

     • Allow multiple integration types: Profiles can have specific entitlements in more than one target integration type (such as one or more entitlements from any Active Directory or Okta integration)

     • Limit to a single integration type: Entitlements must be within integrations of a specific type (such as one or more entitlements from any Okta integration)

     • Limit to a single integration: Profiles are limited to a single integration (such as one or more entitlements from a specific Okta integration)

     • Create a local user account only (if limited to a single integration): Create a local user account without specific entitlements.

   • Entitlements: Set the maximum number of entitlements that can be added to profiles with this type (0 for unlimited entitlements).

     • Access Profile creators and owners can choose specific entitlements when editing the profile.

     • Create New Entitlement if None Exists: Configure the CREATE_ENTITLEMENT action to run when the policy is applied, including:

       • The target integration and entity type to create

       • Any member conditions (ANY to apply to all identities, or restricted by a condition string)

       • Attributes for the created entities using the specified .

       • Enabling Continuous Sync to periodically recreate and reapply entitlements if removed within the target system.

4. Click Create Profile Type to save the changes

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.

Best Practices for Access Profile Types

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

• Inheritance Planning: Carefully plan which profile types should inherit from others to create a logical hierarchy

• Regular Review: Periodically review profile types to ensure they continue to meet your organization's needs

• Good Hygiene: Eliminate profile types that are no longer in use (when the count of Access Profiles with that type equals zero)

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.

All system attributes follow the sys_attr__ prefix convention and cannot be manually set or modified.

Available System Attributes

sys_attr__is_mover

A persistent boolean attribute that indicates whether an identity has undergone changes to monitored properties.

Type: Boolean Persistence: Stored with identity record Available in: Workflow triggers, conditions, and transformers

Configuration: Define monitored properties in the policy configuration:

{
  "mover_properties": ["department", "manager_id", "title", "location"]
}

Workflow Trigger Example:

sys_attr__is_mover eq true

Combined Condition Example:

sys_attr__is_mover eq true and department eq "Engineering" and active eq true

The attribute is automatically set to true when any property in mover_properties changes during identity update. It is cleared when the identity is unchanged in an extraction cycle, and excluded from change detection to prevent recursive updates.

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

sys_attr__would_be_value

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:

IF sys_attr__would_be_value co "@"
  {email | LOWER}
ELSE
  {email | LOWER}@company.com

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

sys_attr__would_be_value_len

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:

IF sys_attr__would_be_value_len le 30
  {first_name | LOWER}.{last_name | LOWER | NEXT_NUMBER, 2, 3}
ELSE IF sys_attr__would_be_value_len le 20
  {first_name | LOWER | FIRST_N, 10}.{last_name | LOWER | NEXT_NUMBER, 2, 3}
ELSE
  {first_name | LOWER | FIRST_N, 1}.{last_name | LOWER | FIRST_N, 1 | NEXT_NUMBER, 2, 3}

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)

• Alternatives with NEXT_NUMBER: l.f2, l.f3, l.f4

Integration with NEXT_NUMBER

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

IF sys_attr__would_be_value_len le 15
  {username | NEXT_NUMBER, 2, 5}
ELSE IF sys_attr__would_be_value_len le 15
  {username | FIRST_N, 13 | NEXT_NUMBER, 2, 5}

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.

Workflow Trigger Properties

The sys_attr__is_mover attribute supports additional trigger properties for fine-grained control:

{
  "trigger_properties": ["department", "location"],
  "trigger_string": "sys_attr__is_mover eq true and active eq true"
}

This workflow triggers only when:

• The identity is marked as a mover (department or location changed)

• The identity is active

• At least one of the trigger_properties has changed since last extraction

Performance Notes

• Mover Detection: Comparison occurs for all properties in mover_properties during each extraction

• Preview Evaluation: Each IF branch with preview attributes requires transformation execution

• Optimization: Place most common conditions first to minimize preview evaluations

• Caching: Preview values are calculated once per condition branch and reused

See Also

• Transformer Functions Reference - Complete list of transformation functions

• Transformers - Attribute transformation concepts and examples

• Policies - Configuring mover properties and workflows

Overview

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

Understanding Fallback Formatters

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.

Use Case: Username 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).

When multiple employees have similar names, this can lead to conflicts:

• John Smith already has jsmith

• Jane Smith already has jsmith1

• James Smith already has jsmith2

When Jennifer Smith joins, the fallback formatter automatically assigns jsmith3, maintaining your naming convention while ensuring uniqueness.

Configuring Fallback Formatters

Fallback formatters can be configured as part of the "Sync Identities" action within a Lifecycle Management workflow:

1. Edit or create a Lifecycle Management policy

2. Edit the workflow containing the Sync Identities action

3. In the Sync Identities action configuration, click Add Fallback

4. Configure the to use as a fallback pattern for the unique attribute that might experience conflicts

5. Close the action sidebar and save your changes to the policy.

Transformer Options for Fallback Formatters

Several transformers can be used for implementing fallback formatters depending on your specific use case.

Using the NEXT_NUMBER Transformer

A typical approach is to use the NEXT_NUMBER transformer, which is specifically designed to generate sequential numerical alternatives when naming conflicts occur.

The NEXT_NUMBER transformer:

• Generates a set of sequential integers as strings

• Takes two parameters: BeginInteger (starting number) and Length (how many numbers to generate)

• Is unique among transformers in that it returns multiple values, making it ideal for fallback scenarios

Other Useful Transformers for Fallbacks

In addition to NEXT_NUMBER, other transformers can be valuable for creating fallback formatters:

Using Random Alphanumeric for Unique Usernames:

This could generate usernames like jsmith8f3d instead of sequential jsmith1, jsmith2, etc.

Using UUID for Guaranteed Uniqueness:

This would append the first 8 characters of a UUID, creating identifiers like jsmith-a7f3e9c2.

Implementation Example

When configuring a fallback formatter with the NEXT_NUMBER transformer:

1. Select the attribute that requires uniqueness (e.g., username, email)

2. Configure the primary pattern (e.g., {first_initial}{last_name})

3. Add a fallback using the NEXT_NUMBER transformer to generate sequential alternatives:

This will generate up to 10 alternatives: jsmith1, jsmith2, ... jsmith10

Common Fallback Patterns

Here are some commonly used fallback patterns:

How Fallback Resolution Works

When Lifecycle Management attempts to provision a new identity with a unique attribute value that already exists:

1. The system first tries the primary format (e.g., jsmith)

2. If a conflict is detected, it automatically tries the first alternative using the NEXT_NUMBER transformer (e.g., jsmith1)

3. If that value also exists, it tries the next alternative (e.g., jsmith2)

4. This process continues until either:

   • A unique value is found

   • All alternatives from the NEXT_NUMBER range are exhausted (in which case an error would be reported)

This automated conflict resolution ensures provisioning can proceed without manual intervention, even when your standard naming conventions result in conflicts.

This guide describes how to enable and configure Active Directory for Lifecycle Management in Veza, including supported capabilities and required configuration steps.

Overview

Active Directory integration with Lifecycle Management enables automated user provisioning, access management, and de-provisioning capabilities. This includes creating and managing AD users, group memberships, and disabling accounts when employees leave the organization.

Supported Capabilities

Identity Provider Status

Active Directory serves as an Identity Provider in Lifecycle Management workflows and supports custom properties defined in the integration configuration.

Supported Actions

Manage Relationships

Controls relationships between users and Active Directory groups.

• Entity Types: Active Directory Groups

• Assignee Types: Active Directory Users

• Supports Removing Relationships: Yes

Example Use Cases:

• Add users to specific Active Directory groups to manage access

• Remove users from groups when access requirements change

Sync Identities

Synchronizes identity attributes between Active Directory and downstream systems.

• Create Allowed: Yes (New user identities can be created if not found)

• Supported Attributes:

  • Required (Unique Identifiers):

    • AccountName (No Continuous Sync)

    • DistinguishedName

    • UserPrincipalName

  • Optional:

    • Email, GivenName, DisplayName, SurName, Title

    • Description, ManagerID, PrimaryGroupDN

    • StreetAddress, City, StateOrProvinceName

    • CountryCode, PostalCode, Company

    • PhysicalDeliveryOfficeName, JobTitle

    • Department, CountryOrRegion, Office

Example Use Cases:

• Create new user accounts when users are added

• Keep user information synchronized across integrated systems

De-provision Identity

Safely removes or disables access when users leave or no longer need access.

• Entity Type: Active Directory Users

• Remove All Relationships: Yes (Removes existing group memberships)

• De-provisioning Method: Disabled (Users are marked as disabled rather than deleted)

Example Use Cases:

• Disable accounts when employees leave

• Remove group memberships while retaining audit information

Configuration Steps

1. Create a Service Account

Create a dedicated AD user with minimum required permissions:

Using Active Directory Users and Computers:

1. Open Active Directory Users and Computers

2. Navigate to the target Organizational Unit

3. Right-click > New > User

4. Complete the new user details form

   • Recommended name: "Veza AD Lifecycle Manager"

   • Set a strong password

   • Uncheck "User must change password at next logon"

Using PowerShell:

New-ADUser -Name "Veza AD Lifecycle Manager" `
    -Path "OU=<your_OU>,DC=<domain>,DC=<tld>" `
    -GivenName "Veza" `
    -Surname "AD Lifecycle Manager" `
    -SamAccountName "veza-ad-lcm" `
    -AccountPassword (ConvertTo-SecureString -AsPlainText "<password>" -Force) `
    -ChangePasswordAtLogon $False `
    -DisplayName "Veza AD Lifecycle Manager" `
    -Enabled $True

2. Configure Required Permissions

Grant the service account permissions to manage users in the target OUs:

Using Active Directory Users and Computers:

1. Navigate to the target Organizational Unit

2. Right-click > Delegate Control

3. Click Add and enter the service account name

4. Select these delegated tasks:

   • Create, delete, and manage user accounts

   • Reset user passwords and force password change

   • Read all user information

   • Modify group membership

Using PowerShell:

Import-Module ActiveDirectory
$OrganizationalUnit = "OU=<your_OU>,DC=<domain>,DC=<tld>"
$Users = [GUID]"bf967aba-0de6-11d0-a285-00aa003049e2"
Set-Location AD:

$User = Get-ADUser -Identity "veza-ad-lcm"
$UserSID = [System.Security.Principal.SecurityIdentifier] $User.SID
$Identity = [System.Security.Principal.IdentityReference] $UserSID

# Create permission for managing users
$RuleCreateDeleteUsers = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $Identity, "CreateChild, DeleteChild", "Allow", $Users, "All"

# Create permission for password resets
$ResetPassword = [GUID]"00299570-246d-11d0-a768-00aa006e0529"
$RuleResetPassword = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($Identity,
"ExtendedRight", "Allow", $ResetPassword, "Descendents", $Users)

# Apply permissions
$ACL = Get-Acl -Path $OrganizationalUnit
$ACL.AddAccessRule($RuleCreateDeleteUsers)
$ACL.AddAccessRule($RuleResetPassword)
Set-Acl -Path $OrganizationalUnit -AclObject $ACL

3. Configure the Integration in Veza

1. Navigate to Configurations > Integrations

2. Either:

   • Create a new Active Directory integration

   • Edit an existing Active Directory integration

3. Enable Lifecycle Management:

   • Check Enable Lifecycle Management

   • Enter the Lifecycle Management Username (service account created above)

   • Enter the Lifecycle Management Password

4. Save the configuration

Note: The AD User created for lifecycle management can be the same as the primary AD User created for extraction, provided that the user has all required permissions listed above.

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

• Custom fields are identified with a customprop_ prefix

• System-computed fields are identified with the sys_attr__ prefix

Attribute Types and Mappings

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

Standard Attributes

Veza recognizes and standardizes many common attributes across source systems:

Source-Specific Mappings

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

Custom Properties

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

• customprop_project_code - Project allocation

System Attributes

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 System Attributes for details.

Using Attributes in Workflows

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

Primary vs Secondary Sources

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

workday_id
employee_id
business_title
hire_date
email
customprop_department_code

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

OktaUser.login
OktaUser.department
AzureADUser.job_title
ActiveDirectoryUser.distinguished_name

Example Usage

In Workflow Conditions:

employee_types co "Full Time" and department eq "Engineering"

In Transformers:

{first_name}.{last_name}@{customprop_domain}.com

With Secondary Sources:

OktaUser.status eq "ACTIVE" and WorkdayWorker.is_active eq true

See Also

• System Attributes - Computed attributes for advanced scenarios

• Transformers - Modifying and combining attribute values

• Policies - Using attributes in workflow conditions

Before you begin creating draft 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.

Key considerations and requirements

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

  • At least one source of identity is required to trigger Lifecycle Management actions when there are changes in the data source. This data source could be an HRIS system, identity provider, directory service, or an exported report.

  • Veza supports importing employee records from built-in , OAA integrations using the , and .

  • For example, you may have different sources of identity for full-time and employees and contractors.

• What scenarios will be automated?

  • A range of applications can be sources of identity and targets for Lifecycle Management, with different actions supported for each integration. See and for the current capabilities.

Define Segmentation Criteria (Business Roles)

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

5. Define and list the different populations of employees with different levels of access in your organization (such as by roles, regions, and teams).

6. Organize the populations hierarchically, each inheriting the access granted to its parent population. For example, you might have a structure "All Employees" > "Sales Team" > "Sales Managers," with each inheriting the access granted to the parent.

7. Create a in Veza to model each segment.

Example Business Roles:

• Sales

• Developers

• Executive Employees

• US Employees

• China Employees

Define Role Conditions

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

OAA HRIS Built-In Attributes

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"

• Cost Center equals "R&D"

• Start Date on or after "2025-01-01"

Define Profiles

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.

Map Business Roles to Profiles

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

Define synced attributes

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

The Veza integration for GitHub enables automated user lifecycle management, with support for user provisioning, team membership management, and account deprovisioning.

This document includes steps to enable the GitHub integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.

Enabling Lifecycle Management for GitHub

Prerequisites

1. You will need administrative access in Veza to configure the integration and site administrator privileges in GitHub Enterprise Server.

2. Ensure you have an existing GitHub integration in Veza or add a new one for use with Lifecycle Management.

3. Verify your GitHub integration has completed at least one successful extraction

4. The GitHub integration will need the additional required GitHub App permissions:

   • Organization permissions - Members (Write) - Required for managing organization memberships

   • Organization permissions - Administration (Write) - Required for administrative operations

   • Repository permissions - Administration (Write) - Required for managing team memberships

Important: GitHub LCM operations use Admin API endpoints that require site administrator privileges. These operations are typically available in GitHub Enterprise Server environments, not GitHub.com.

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create a GitHub integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your GitHub data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for GitHub in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Supported Actions

GitHub can be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.

The integration supports the following lifecycle management Actions:

Sync Identities

Primary action for user management (creating or updating users):

• User login cannot be changed after creation

• GitHub usernames must be unique and follow GitHub naming rules (39 characters max, alphanumeric plus hyphens)

• Email addresses must be unique across the GitHub instance

• Requires site administrator privileges for user creation operations

The following attributes can be synchronized:

Manage Relationships

Both adding and removing memberships are supported. Organization and team memberships are automatically removed during deprovisioning.

• Add and remove organization memberships with member role

• Add and remove team memberships with member role

• Synchronize access assignments based on external identity changes

• Track membership changes for audit purposes

Deprovision Identity

When a user is deprovisioned:

• User account is suspended in GitHub Enterprise Server

• All organization and team memberships are removed automatically

• Commit history and attribution are preserved for audit and compliance

• Account can be reactivated if needed (unsuspended)

• User receives appropriate error messages when attempting to access GitHub

Workflow Examples

New Employee Onboarding

Create GitHub accounts and assign appropriate access for new developers:

1. Identity Sync: Create user account with basic profile information

2. Organization Access: Add user to primary GitHub organization

3. Team Assignment: Assign to development teams based on department

4. Profile Setup: Configure public email and display name

Role Change Management

Update GitHub access when employees change departments or roles:

1. Relationship Updates: Remove existing team memberships

2. New Access: Add memberships for new role requirements

3. Audit Trail: Track all membership changes for compliance

Employee Offboarding

Securely remove access while preserving development history:

1. Account Suspension: Suspend GitHub account to prevent access

2. Membership Removal: Remove all organization and team memberships

3. History Preservation: Maintain commit attribution and repository history

4. Compliance: Generate audit trail of all access removal actions

This guide describes how to enable and configure Workday for Lifecycle Management in Veza, including supported capabilities and configuration steps.

Overview

Workday integration enables automated Lifecycle Management workflows using Workday as a source of truth for employee identity information, including:

• Automated security group assignments for new employees

• Dynamic group membership updates during role changes

• Access removal during offboarding

• Email synchronization between Workday and downstream systems

Supported Capabilities

Source of Identity

Workday serves as an authoritative source for employee identity information:

• Entity Type: Workday Worker

• Purpose: Used as the source of truth to trigger lifecycle management workflows based on worker record changes

Lifecycle Actions

Manage Relationships

Controls access to Workday security groups.

• Entity Types: Workday Security Group

• Assignee Types: Workday Account

• Supports Relationship Removal: Yes

Write Back Email

Updates email addresses in Workday worker records to maintain consistency with other systems.

• Entity Type: Workday Worker

• Purpose: Ensures Workday remains the single source of truth for employee email addresses

Custom Properties

The integration supports custom attributes defined in your Workday configuration, which can be used in lifecycle management conditions and transformers.

Configuration Steps

1. Create Business Process Security Policy

1. Log into Workday and search for Edit Business process security policy

2. Under Business Process Type, select Work Contact Change
3. Find "Initiating Action: Change Work Contact Information (REST Service)"

4. Create a Segment-Based Security Group
5. Configure the security group:

   • Add the security group created for Veza integration

   • Add "Worker" scope to Access Rights
6. Verify the security group appears in Initiating Action Security groups
7. Click OK and Done to save changes

2. Activate Security Policy Changes

1. Search for Activate Pending Security Policy Changes

2. Review changes, add a comment, and click OK
3. Verify changes in Business Process Security Policy

3. Configure Security Group Permissions

Add these Domain Permissions to the security group:

4. Update API Client Configuration

1. Open Edit API Client

2. Add required scopes:

   • Staffing

   • Contact Information

   • System

   • Tenant Non-Configurable

   • Organizations and Roles

5. Configure Workday Integration in Veza

1. Navigate to Configurations > Integrations

2. Either:

   • Create a new Workday integration

   • Edit an existing Workday integration

3. Enable Lifecycle Management:

   • Check Enable Lifecycle Management

4. If using custom attributes, configure them in the Custom Properties section

API Access Notes

The integration uses these API endpoints for email write-back:

%s/ccx/api/person/v3/%s/workContactInformationChanges/%s/emailAddresses
%s/ccx/api/person/v3/%s/workContactInformationChanges/%s/submit
%s/ccx/api/staffing/v5/%s/workers/%s/workContactInformationChanges

For general metadata discovery, WQL queries access:

• allWorkdayAccounts

• allWorkers

• securityGroups

• domainSecurityPolicies

• businessProcessTypes

Implementation Notes

1. Workday Workers are the primary entity for identity information

2. Bidirectional management of Account-Security Group relationships is supported

3. Email write-back operates on Worker entities, not Account entities

4. Custom attribute availability depends on your Workday configuration

5. The Sync Identities action is not currently supported for Workday

Overview

The Veza integration for Oracle DB enables automated user provisioning, access management, and deprovisioning capabilities. This integration allows you to synchronize identity information, manage group memberships, and automate the user lifecycle from onboarding to offboarding.

This document outlines the steps to enable Oracle DB integration for use in Lifecycle Management, including supported actions and relevant notes. See for more details.

Enabling Lifecycle Management for Oracle DB

Prerequisites

1. You will need administrative access in Veza to configure the integration.

2. Ensure you have an existing integration in Veza or add a new one for use with Lifecycle Management.

3. Verify your Oracle DB integration has completed at least one successful extraction.

4. Database administrator privileges in Oracle DB (ability to create common users and grant privileges)

5. For multi-tenant configurations: access to CDB$ROOT container

6. Supported Oracle Database versions: 19c, 21c, or 23ai

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create an Oracle DB integration

3. Check the box, Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your Oracle DB data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for Oracle DB in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Supported Actions

Oracle DB can serve as a source for identity information in Lifecycle Management . User identity details are synchronized from Oracle DB, with changes propagated to connected systems.

Oracle DB can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.

The integration supports the following Lifecycle Management :

Sync Identities

The following attributes can be synchronized:

SYNC_IDENTITIES

• Entity Type: OracleDB User

• Create Allowed: Yes

• Method: SQL CREATE USER / ALTER USER

MANAGE_RELATIONSHIPS

• Entity Types: OracleDB Role

• Assignee Types: OracleDB User

• Supports Remove: Yes

• Method: SQL GRANT ROLE / REVOKE ROLE

DEPROVISION_IDENTITY

• Entity Type: OracleDB User

• Method: DISABLED (account lock via ALTER USER ... ACCOUNT LOCK)

• Removes Relationships: Yes

DELETE_IDENTITY

• Entity Type: OracleDB User

• Method: Permanent deletion via DROP USER

Workflow Examples

Employee Onboarding

1. Create an Oracle DB user account with the Sync Identities action

2. Assign default role based on department with Manage Relationships

3. Set password (requires change on first login)

4. Configure profiles and tablespaces

Role Change Management

1. Update user attributes (profile, tablespaces) with Sync Identities

2. Remove old role assignments with Manage Relationships

3. Grant new roles appropriate for the new position

Employee Offboarding

1. Lock user account with Deprovision Identity (ACCOUNT LOCK)

2. Remove all role assignments

3. Preserve the user record for audit purposes

4. Optional: Delete user permanently with Delete Identity (DROP USER)

Overview

The Veza integration for Snowflake enables automated user lifecycle management, with support for user provisioning and de-provisioning, role assignment management, and attribute synchronization.

This document includes steps to enable the Snowflake integration for use in Lifecycle Management, along with supported actions and notes. See for more details.

Enabling Lifecycle Management for Snowflake

Prerequisites

1. You will need administrative access in Veza to configure the integration and USERADMIN role or equivalent privileges in Snowflake.

2. Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.

3. Verify your Snowflake integration has completed at least one successful extraction

4. The Snowflake integration will need the additional required privileges:

   • CREATE USER privilege on the account for user provisioning

   • GRANT ROLE privilege for role assignments

   • OWNERSHIP privilege on target roles for role management

   • Access to a warehouse for executing queries during lifecycle operations

Important: The Snowflake user account used for Lifecycle Management operations should have USERADMIN role or higher privileges to ensure proper user and role management capabilities.

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create a Snowflake integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your Snowflake data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for Snowflake in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Supported Actions

Snowflake can be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.

The integration supports the following lifecycle management :

Sync Identities

Primary action for user management (creating or updating users):

• User names must be unique and follow Snowflake identifier naming conventions

• Login names are used for authentication and must be unique

• Passwords are automatically generated and set to require change on first login

• Users are created with appropriate default settings for the Snowflake environment

The following attributes can be synchronized:

Manage Relationships

Role assignment management for users:

• Add and remove role assignments for users

• Synchronize role memberships from source systems

• Support for direct role grants to users

• Roles must exist in Snowflake before assignment

Within Snowflake, roles can be associated with:

• Database and schema access permissions

• Table and view privileges

• Warehouse usage rights

• Administrative privileges for account management

Deprovision Identity

When a user is deprovisioned:

• User account is disabled (set DISABLED = TRUE)

• Role assignments are removed to revoke access

• User attributes are preserved for audit purposes

• Account can be reactivated if needed for compliance requirements

Workflow Examples

Employee Onboarding

Automated provisioning when a new employee joins:

1. Create User Account: Sync identity attributes from HR system to create Snowflake user with name and login details

2. Assign Department Role: Grant role based on department attribute (e.g., SALES_ANALYST, DATA_ENGINEER)

3. Set Default Role: Configure default role for the user's session

4. Add Email and Comments: Populate user profile with contact information and descriptive notes

Role Change Management

Managing access when employees change roles:

1. Update User Attributes: Sync changed attributes like email or comments

2. Remove Old Roles: Revoke previous role assignments that are no longer appropriate

3. Grant New Roles: Assign roles appropriate for the new position

4. Update Default Role: Change the user's default role for new sessions

Employee Offboarding

Secure access removal when employees leave:

1. Disable Account: Set user account to disabled status

2. Revoke All Roles: Remove all role assignments to eliminate data access

3. Preserve Audit Trail: Maintain user record and history for compliance

4. Optional Cleanup: Remove user completely with DROP USER if no audit trail is needed

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.

Activity Log Tabs

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.

Events Tab

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.

Jobs Tab

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.

Actions Tab

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 Actions for more details on supported actions and configuration options.

Workflow Tasks Tab

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

Workflow Execution Process

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)

   • Continuous sync settings

   • Last execution time (for unchanged identities)

3. Task Creation: If execution is needed, a workflow task is created

4. Action Execution: The system executes conditions and actions via the task runner

5. Result Storage: The result is stored as an event in the Activity Log

Using the Activity Log

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

• View error messages: Review issues by checking for error messages in the Message column

Log Retention and Security

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.

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

Understanding Policies, Workflows, and Actions

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

Policies

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

• Specify which source of identity triggers the automation

• Can contain multiple workflows to handle different scenarios (joiner, mover, leaver)

• Support continuous synchronization to keep identities up-to-date

• Enable email notifications and webhooks for action-related events

Workflows

• Define specific sequences of actions that execute based on trigger conditions

• Handle different lifecycle scenarios (e.g., new hire onboarding, role changes, terminations)

• Support conditional execution based on user attributes (department, location, role, etc.)

• Allow for complex decision trees through nested conditions

• Execute actions in a defined order when conditions are met

Conditions

• Define when specific actions should occur within a workflow

• Can be based on any attribute from the source of identity

• Support SCIM filter expressions for precise targeting

• Can be nested to create sophisticated logic trees

• Can trigger multiple actions when met

• Can spawn additional conditions after successful action completion

Example Conditions for Lifecycle Management Actions:

• Add to engineering groups based on department: department eq "Engineering"

• Grant manager access based on role: is_manager eq true

• Assign cost center groups: cost_center eq "IT-1234"

• Add to contractor AD groups: employment_type eq "CONTRACTOR"

Actions

• Represent specific tasks such as creating users, syncing attributes, or managing access

• Types of actions include:

  • SYNC_IDENTITIES: Create/update user accounts

  • MANAGE_RELATIONSHIPS: Grant/revoke access

  • CREATE_EMAIL: Generate email addresses

  • DEPROVISION_IDENTITY: Disable/remove access

  • WRITE_BACK_EMAIL: Update source system

  • PAUSE: Add workflow delays

  • SEND_NOTIFICATION: Trigger alerts

Example Conditions and Actions: Provisioning to Active Directory

The following workflow configuration for a Lifecycle Management Policy enables provisioning actions for Active Directory users when workers are added in Workday:

• Create an Active Directory user, synchronizing attributes with the source Workday Worker

• Create email addresses for new employees in Exchange Server

• Update the Workday Worker and AD User records to include the new email

• Grant entitlements by assigning Access Profiles according to the Worker's department

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

When provisioning users, Veza synchronizes attributes for active employees and creates them during AD User provisioning. These attributes can be transformed from attributes in the source of identity (Workday):

Sync Active Directory Attributes for Withdrawn Employees (Leavers)

To de-provision users, Veza moves accounts to a terminated users group and adds them to an OU 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

Action Types

Note on Action Hierarchy: The "Sync Identities" action is the only action type that can be declared at the root condition level. All other actions (such as Manage Relationships, Create Email, etc.) must be defined within sub-conditions after establishing a root condition with "Sync Identities". The UI enforces this hierarchy and will show a warning when adding non-Sync actions at the root level.

Sync Identities

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

Manage Relationships

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

Create Email

Integrates with an email provider to create email addresses for identities. This action is often used in combination with other actions in new hire and temp-to-hire workflows.

Example Use Cases:

• Create corporate email accounts for new employees

• Establish shared mailboxes for teams or projects

Deprovision Identity

Safely removes or disables access for identities when they withdraw from the organization.

Example Use Cases:

• Disable accounts when employees or contractors leave

• Revoke access while maintaining audit records

• Transition resources and non-human identities when owners depart

Write Back Email

Updates HRIS or other systems with email addresses created in other actions.

Example Use Cases:

• Update employee records with newly created email addresses

• Sync email information back to master HR systems

• Ensure consistent email records across all platforms

Pause

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

Send Notification

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

Email Template Selection:

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 Notification Templates for placeholder reference and template management.

Overview

This document provides an introduction to the integrations supported by Veza Lifecycle Management (LCM), including their capabilities and the actions they support. These integrations enable you to automate identity and access management workflows across your identity sources and target applications.

Veza's Open Authorization API (OAA) can support provisioning and deprovisioning for applications not natively supported by the Veza platform. With OAA, Veza or customers can build integrations to any application that has a suitable and accessible API or integration interface.

Supported Integrations

Identity Sources

Identity sources are authoritative systems that provide information about user identities. While Veza does not require write permissions to the identity source of truth, some of these integrations are also supported as provisioning targets. Integrations can also allow write-back of a user's newly created email address to the user's record in the source of identity as part of the initial provisioning workflow.

Veza currently supports the following as sources of identity for Lifecycle Management workflows:

Target Application Support

The entire catalog of Veza application integrations is Lifecycle Management-ready. Target application support in Lifecycle Management leverages Veza's existing native- and OAA-based integrations plus an intelligent shim layer in order to provide support for provisioning and de-provisioning.

As such, target application support in Lifecycle Management can be enabled for nearly every Veza-supported integration.

Validated Integrations

The following table lists the out-of-the-box, Veza-validated target application integrations for Lifecycle Management.

Other Supported Integrations

For any Veza-supported application not listed above, please contact your Customer Success Manager for more details and instructions on how to enable the specific Veza integration for use with Lifecycle Management as a target application for provisioning and de-provisioning.

Configuring Integrations for Lifecycle Management

Insight Points for Lifecycle Management

An Insight Point is required to enable Lifecycle Management operations and identity discovery for systems that Veza cannot access directly, such as an on-premises application server behind a firewall. The Insight Point is a lightweight connector that runs in your environment, enabling secure gathering and processing of authorization metadata for LCM tasks.

A Veza Insight Point is typically deployed as a Docker container or VM OVA, running within your network for metadata discovery and LCM job execution. This ensures secure communication between your environment and Veza.

For deployment instructions, refer to the .

Scheduled and Manual Extractions

You can configure extraction intervals for your integrations to ensure data is regularly updated for Lifecycle Management processes.

1. Go to Veza Administration > System Settings

2. In the Pipeline > Extraction Interval section, set the global extraction interval

3. To override the global setting for specific integrations, use the Active Overrides section

Available extraction intervals are:

• Auto (hourly, but may take longer when the extraction pipeline is full)

• 15 Minutes

• 1 Hour

• 6 Hours

• 12 Hours

• 1 Day

• 2 Days

• 3 Days

• 7 Days

• 30 Days

To manually trigger an extraction:

1. Go to Integrations > All Data Sources

2. Search for the desired data source

3. Select Actions > Start Extraction

Note: Custom application payloads are extracted after the payload is pushed to Veza using the Open Authorization API.

Enabling Lifecycle Management

To enable Lifecycle Management for a specific integration:

1. Browse to the main Veza Integrations page, or go to Lifecycle Management > Integrations

2. Search for the integration you want to enable

3. Toggle the Lifecycle Management option to Enabled

Checking on Lifecycle Management Data Sources

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Additional Resources

For more information:

• Refer to individual integration documentation for detailed LCM capabilities

• Consult the Lifecycle Management user guide for troubleshooting and best practices

• Contact Veza support for assistance with enabling or configuring LCM for your integrations

Overview

The Veza integration for Okta enables automated user lifecycle management, with support for user provisioning and de-provisioning, group membership management, and attribute synchronization.

This document includes steps to enable the Okta integration for use in Lifecycle Management, along with supported actions and notes. See for more details.

Enabling Lifecycle Management for Okta

Prerequisites

1. You will need administrative access in Veza to configure the integration and grant API scopes in Okta.

2. Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.

3. Verify your Okta integration has completed at least one successful extraction

4. The Okta integration will need the additional required API scopes:

   • okta.users.manage - For user lifecycle operations

   • okta.groups.manage - For group membership management

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create an Okta integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your Okta data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for Okta in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Supported Actions

Okta can serve as a source for identity information in Lifecycle Management . User identity details are synchronized from Okta with changes propagated to connected systems

Okta can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow:

The integration supports the following lifecycle management :

Sync Identities

Primary action for user management (creating or updating users):

• Login ID cannot be changed after creation

• Email addresses must be unique

• Required attributes must be present (login, email, first_name, last_name)

The following attributes can be synchronized:

Manage Relationships

Both adding and removing memberships are supported. Group memberships are removed in deprovisioning.

• Add and remove group memberships

• Synchronize group assignments

• Track membership changes

Deprovision Identity

When a user is deprovisioned:

• User account is disabled

• Group memberships are removed

• Attribute history is preserved for audit

• Account can be reactivated if needed

Create Entitlement

• Entity Types: Okta Groups

• Assignee Types: Okta Users

• Supports Relationship Removal: Yes

Within Okta, groups can be associated with:

• Application group assignments controlling SSO access

• Permissions to resources within specific applications

• Synchronized AWS SSO groups

• Role-based access controls within Okta

Reset Password

Allows password reset operations for Okta users:

• Requires the login attribute as a unique identifier

• Non-idempotent action (each execution creates a new password reset event)

• Will trigger Okta's standard password reset flow for the specified user

Overview

The Veza integration for Coupa Contingent Workforce (CCW) enables automated identity synchronization as a source of truth for contingent worker lifecycle management. Coupa CCW serves as an authoritative source for contingent worker information that can be synchronized with other systems in your environment.

This document includes steps to enable the Coupa CCW integration for use in Lifecycle Management, along with supported actions and notes. See for more details.

Enabling Lifecycle Management for Coupa CCW

Prerequisites

1. You will need administrative access in Veza to configure the integration and Customer Integration Admin privileges in Coupa CCW.

2. Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.

3. Verify your Coupa CCW integration has completed at least one successful extraction

4. The Coupa CCW integration will need the required API scope:

   • ccw.contingent_workers - For accessing contingent worker data

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create a Coupa CCW integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your Coupa CCW data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for Coupa CCW in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Supported Actions

Coupa CCW can serve as a source for identity information in Lifecycle Management . Contingent worker identity details are synchronized from Coupa CCW with changes propagated to connected target systems.

Important: Coupa CCW is a source-only integration for Lifecycle Management. It provides authoritative identity information but cannot be used as a provisioning target.

The integration supports the following lifecycle management :

Source of Identity

As a source-only system, Coupa CCW provides:

• Contingent worker identity information synchronized to downstream systems

• Organizational structure data (Account Segments, Cost Centers, Departments)

• Employment status and contract details for lifecycle decisions

• Manager relationships for approval workflows

Workflow Examples

Contingent Worker Onboarding

When a new contingent worker is added to Coupa CCW:

1. Identity Sync: Coupa CCW provides worker details to Veza Lifecycle Management

2. Access Provisioning: Based on department, cost center, and role, appropriate access is granted in target systems

3. Manager Assignment: Hiring manager relationships are established for approval workflows

4. Group Assignment: Worker is added to relevant organizational groups based on Account Segment and Department

Contingent Worker Status Changes

When a contingent worker's status changes (contract end, role change):

1. Status Detection: Coupa CCW reflects updated employment status

2. Access Review: Lifecycle policies evaluate continued access needs

3. De-provisioning: If terminated, appropriate access removal is triggered in target systems

4. Audit Trail: All changes are tracked for compliance reporting

Contract-to-Hire Conversion

When a contingent worker transitions to full-time employee:

1. Status Update: Employment type change is detected in Coupa CCW

2. Access Migration: Existing access is evaluated and potentially expanded

3. System Updates: Worker identity is updated across all connected systems

4. Process Completion: Manager and HR notifications confirm successful transition