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.

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

• What scenarios will be automated?

Define Segmentation Criteria (Business Roles)

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.

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

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.

Examples: Access Profiles

Map Business Roles to Profiles

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.

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.

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.

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, which could include 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 of how access should be assigned to different groups of employees. Administrators can position child profiles underneath a parent profile, with each child profile inheriting the entitlements from the parent profile.

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

Example Profiles

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

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

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

• Any entitlements inherited from a parent Profile.

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

Access Profile Types

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

Profiles

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

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

Business Roles

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

Best Practices for Access Profile Types

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

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

Configuring Access Profiles

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

1. Click Create Access Profile

2. Under Access Profile Details, choose the Profile Type to create:

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

   2. Profile: Profiles define entitlements that can be assigned to users in target applications, such as groups, roles, or permission sets assigned to users as birthright entitlements. Profiles cannot be inherited from other Access Profiles, but can be inherited by Business Roles. Use this profile type to define the birthright entitlements within one or more applications (such as group memberships or role assignments).

3. Profile Name and Description: You should follow a standard naming convention for all profiles to help identify them, describing the employee segment or applications the Access Profile applies to.

4. Profile Labels: Labels are available for quickly finding access profiles when configuring actions in a policy. Apply and create labels as needed to organize your Access Profiles by the employee segments and applications they apply to.

5. Assigned Relationships:

   1. Click Add Relationship

   2. Choose the type of relationship to add:

      • Access Profile: Use the Relationship menu to pick one or more Access Profiles to grant those business roles or entitlements. This option is not available for Access Profiles with the "Profile" type.

      • Relationship: Choose the target data source and specific entities the Profile will govern access to (such as Google Cloud Platform > Google Group). This option is not available for Access Profiles with the "Business Role" type.

6. Click Assign to save the changes.

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

When configuring a policy to include the Manage Relationships action, you can choose from any active profiles for the target data source.

See Also

When creating workflows in Lifecycle Management policies to create, sync, or de-provision identities, you will use attribute transformers to specify how user attributes for target accounts should be structured. The target attributes to create or update are typically mapped and optionally transformed from user metadata from the source of identity, such as an identity provider, HR system, or CSV upload. Attributes can be synchronized once or kept in continuous sync as changes occur over the user’s lifetime.

For example, attribute mapping and transformation can be used across Joiner, Mover, and Leaver scenarios:

• Joiner: Set new Azure AD User Principal Name to {source username}@{your-email-domain.com}. This is an example of mapping multiple attributes and performing a transformation.

• Mover: Always update a user’s “Manager” and “Department” attributes in Okta to match the user’s manager and department in Workday, a source of identity, whenever a department change or other employee mobility event occurs. This is an example of attribute mapping with continuous synchronization.

• Leaver: Mote a user’s Active Directory account to an OU reserved for terminated accounts.

When synchronizing a user’s attributes, Veza can apply one (or more) transformations to convert the source attribute values to a more suitable format, and apply the result within the target application as user account attribute.

For example, a transformer might remove the domain from an email address, replace special characters, or convert a string from upper case to lower case. Transformers can apply to any attribute on the target user account with the complexity varying depending on your business requirements.

See the following sections for more information about formatting destination attributes and possible transformations:

Continuous Sync

Continuous Sync keeps identity attributes in target systems up to date with your source of truth. It has three configuration levels that work together to determine how attributes are synchronized:

Workflow Level

The workflow's continuous sync setting controls change detection:

• When enabled: The workflow monitors for any changes in the source system

• When disabled: The workflow only runs during initial provisioning

Action Level

For Sync Identity actions, this controls whether existing entities can be updated:

• When enabled: The action can update existing entities

• When disabled: The action only sets attributes during initial creation

Attribute Level

Individual attributes can be configured for continuous sync:

• When enabled: The attribute will be updated when changes are detected

• When disabled: The attribute is only set during initial creation

All three levels must be enabled for an attribute to be continuously synchronized. For example, if you want to keep an employee's department updated:

1. Enable continuous sync on the workflow to monitor for changes

2. Enable continuous sync on the sync action to allow updates

3. Enable continuous sync on the department attribute transformer

Recommended Settings

Enable continuous sync for attributes that change during employment:

• Employee name

• Department

• Title

• Manager

• Cost Center

• AD Distinguished Name (DN)

• AD User Principal Name (UPN)

• AD Email

Disable continuous sync for stable identifiers:

• Active Directory sAMAccountName

• Email Addresses (for Email Write-Back action)

This configuration ensures that dynamic attributes stay updated while preserving stable identifiers.

Common Transformers

As part of implementing lifecycle management processes with Veza, you should create sets of common transformers to define how values such as username, login, or ID should be sourced for each target application. These transformers can then be reused across all identity sync and de-provision workflows involving those targets. Create common transformers to consistently form attributes for specific entity types, and re-use them to avoid errors and save time when creating actions for that entity type.

For instance, defining a common synced attribute to describe how to format Azure AD account names {username}@evergreentrucks.com enables reuse across multiple workflow actions. You can also define synced attributes at the action level when they are used only once within a policy, such as setting the primary group DN and OU of de-provisioned identities to a group reserved for terminated accounts.

Common Transformer Examples:

Adding transformers

Transformers can be defined at the policy level or when configuring an individual action in a workflow. To configure a transformer, add basic details as well as how to source the value of each attribute:

1. Give the transformer a name and description, and specify the data source it applies to.

2. Entity Type: Choose the target entity type in the destination system.

3. Click Add Attribute. The Destination Attribute dropdown will list available attributes for the chosen entity type.

   1. Destination Attribute: Choose the attribute that Veza will create or update for the target entity.

   4. Continuous Sync: Enabling this option always syncs the attribute, whilst applying any defined transformations. By default, attributes will not sync if the target identity is already created.

After creating a common transformer, you can select it when editing a workflow action. You can edit or delete common transformers on the Edit Policy > Common Transformers tab.

Remember that “Sync Identity” and “De-Provision Identity” actions can have action-level transformers override common transformers. If the same destination attribute is defined in both, the action-level transformer will take precedence.

Formatters

Formatters specify the actual value of the attribute to synchronize. The target attribute can be set to a specific value, synchronized with a source attribute, transformed according to a function, or some combination of the three.

Note that some formatters should enable continuous synchronization for the attribute, while others should not. For example, the value of “Created By” should be immutable once a user account is provisioned. Other attributes that represent a state or status should be synchronized over the user or account lifecycle.

Simple Value Setting

To create a destination attribute with a fixed value, enter the desired value when configuring the formatter.

For setting the creator attribute:

For activating a re-hired employee:

Empty Values

To set empty values (common for de-provisioning flows):

Source of Identity Formatters

Target attributes can be updated based on attributes belonging to the source of identity. To reference the value of a source entity attribute, use the format {<source_attribute_name>}.

Examples:

Transformation functions

Based on the user metadata that is available from your source of identity, you may need to convert a full email address to a valid username, standardize a date, or generate a unique identifier for users provisioned by Veza. If an attribute value needs to be altered for compatibility with the target system, you can transform the value of a source attribute, or apply a range of other functions to generate the target value.

Formatter expressions use the following syntax: {<source_attribute_name> | <FUNCTION_NAME>,<param1>,<param2>}

For example:

Table of transformation functions

See the table below for all supported functions and parameters. Some commonly used transformation functions include:

• Replacing a character with a different one

• Removing domains from email addresses

• Transforming to upper, lower, camel, or snake case

• Using a substring from the original value

Please contact Veza if additional transformations are required for your use case.

Using the ASCII Transformer

The ASCII transformer is particularly useful when working with international user data or systems that have strict character limitations. This transformer performs two main operations:

1. Removes all non-printable characters (including control codes, zero-width spaces, tabs, and newlines)

2. Converts non-ASCII characters to their closest ASCII equivalents

Whereas the REMOVE_DIACRITICS transformer only removes accent marks while preserving the basic character, the ASCII transformer performs a more comprehensive conversion, replacing characters like "Ł" with "L" and handling a wider range of non-ASCII characters.

Pipeline Functions

You can pipeline multiple transformation functions together, separated by a |. Each will apply in sequence, allowing for complex attribute formatters that use the output of one function as the input of another.

Example Pipeline Functions

• {name | UPPER}

  • If name = Smith, the result is SMITH.

• {first_name | SUB_STRING,0,1 | LOWER}.{last_name | LOWER}

  • If first_name = John and last_name = Smith, the result is j.smith.

• {email | REMOVE_DOMAIN}

  • If email = john.smith@domain.com, the result is john.smith.

• {email | REPLACE_ALL, " ", "."}

  • If email = john smith@domain.com, the result is john.smith@domain.com.

• {location | LOOKUP locationTable, location_code, city}

  • If location = IL001, the result is Chicago (using a lookup table named locationTable).

Further reference

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

Examples

1. Geographic Information:

   • Transform location codes to country, region, city, or timezone information

   • Map office codes to physical addresses or facility types

2. Organizational Mapping:

   • Convert department codes to department names or business units

   • Map cost centers to budget codes or accounting categories

3. System-Specific Configurations:

   • Transform job titles to role designations in target systems

   • Convert skill codes to certification requirements or training needs

How It Works

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 Table Structure

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:

Creating and Managing Lookup Tables

Creating a Lookup Table

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

4. Provide a Name and optional Description for the lookup table

5. Drag a CSV file or click Browse to upload your reference data

6. Review the automatically detected column names

7. Click Save to store the lookup table

Managing Lookup Tables

From the Lookup Tables tab, you can:

• Edit table descriptions or upload a new CSV

• Delete tables that are no longer needed

Using Table Lookup Transformers

Basic Syntax

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 Pipeline Functions, 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> is the column in the table to match against

• <return_column_name> is the column containing the value to return

Examples

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

Advanced Features

Pipeline Transformations

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.

Default Values

If you need to handle cases where a lookup value is not found in the table, you can implement this by including a "wildcard" or default row in your lookup table:

This enables any unmatched values to return a default mapping instead of failing.

Technical Details

Implementation Notes

• 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

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

Best Practices

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.

Troubleshooting

Common Issues

Related Topics

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.

Enabling Lifecycle Management for Okta

Prerequisites

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

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 also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow:

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

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 when provisioning AD Users. 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 a 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

De-provision 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

Overview

Lifecycle Management policies define the workflows that are triggered when a user is added or other events are detected at a specific source of identity. This might include hiring a new employee, terminating an existing employee, or other status changes. Workflows contained in a policy describe conditional sequences of actions that can be structured based on the specific joiner, mover, leaver (JML) scenarios that you want to automate.

A policy can contain one or more workflows that run under different conditions. For example, one workflow might apply when employees enter an "Active" state (for Joiner/Re-hire scenarios), and another when an employee becomes "Inactive" (for Leaver scenarios). A workflow could also trigger when an employee hire date is within a certain threshold, such as less than 4 days away, or relative to any other employee property within the source of identity.

For most enterprise deployments, Veza recommends:

• One policy for each source of identity integrated with Lifecycle Management

• Two workflows within each policy:

  • One for active users to cover Joiner and/or Mover scenarios (including Re-hire)

  • Another for inactive users to cover Leaver scenarios

Add a Lifecycle Management Policy

To create a policy for a source of identity:

1. Go to Lifecycle Management > Policies

2. Click Create Policy

3. Give the policy a name and description

   • The policy name is used to identify it on the Policies list and appears in event logs

   • The name should indicate the source of identity the policy applies to

4. Choose the Data Sources the policy will apply to

   • Use the dropdown menu to select the source of identity that will trigger workflows in the policy

   • To appear on this list, the integration must have Lifecycle Management enabled and be available as a source of identity
5. Save the policy

Edit a Lifecycle Management Policy

To edit a policy:

1. Go to Lifecycle Management > Policies

2. Choose a policy from the list and click Edit

3. Configure the policy summary, details, and identity source.

4. Click on a tab in the policy builder to configure its settings:

   • Workflows: Configure the actions that trigger when there are changes in a source of identity

   • Common Transformers: Define shared rules for creating or updating target attributes when provisioning, syncing, or de-provisioning identities

   • Notifications: Configure email notifications or webhooks for the policy's workflows, with different notification rules for different types of events (e.g., "Create Identity" or "Delete Identity")

5. Save the policy

Enabling and Monitoring Lifecycle Management Policies

Use the Policies page for an overview of initial, running, and paused Policies. New policies are created in the "Initial" state, enabling a review period before activating the policy. Active ("Running") policies will apply the next time the data source is extracted.

To manage policies on the main Policies overview:

1. Go to Lifecycle Management > Policies

2. Find the policy you want to manage

   • Search for a specific policy by name

   • Filter to show all providers by their current state

3. Click the ⋮ icon in the rightmost column to expand the Actions menu

4. Choose to Edit, Pause, View Details, or Delete the policy

Adding Workflows to Policies

Policies contain one or more workflows that typically correspond to Active and Inactive user states. Workflows define a sequence of actions to run when a condition is met, based on events and user changes captured at the source of identity. These workflows apply to scenarios such as new employee hiring, department changes, or employee departures.

Workflows contain a tree-like sequence of conditions to meet specific requirements of your joiner, mover, and leaver processes. For example, you may want to grant specific entitlements to users with specific roles, locations, or groups.

Workflows can trigger:

• As soon as an identity is detected with a matching attribute

• Relative to an attribute containing a date (such as before or after a hire_date or termination_date)

• Based on any attribute available from the source of identity

Create a Workflow in a Policy

To add a workflow to a policy:

1. Edit a policy and open the Workflows tab

2. Click Add Workflow to open the sidebar for adding details and conditions

3. Use the General tab to configure workflow settings:

   Workflow Details:

   • Name and Description: Identify the workflow's purpose

   • Continuous Sync: Enable to update target entities when source identity changes occur

   Condition:

   • Workflow Condition: Specify the trigger attribute and value

   • Supports SCIM query syntax for filter expressions

   • Examples:

     • employment_status eq "WITHDRAWN" for terminated employees

     • employment_status eq "ACTIVE" for new hires and movers

   Workflow Trigger Details:

   • Attribute to Get Execute Date: Specify when workflow actions should run

   • Local Time Zone Diff From UTC: Set your UTC offset

     • Eastern Standard Time (EST): -5

     • Pacific Standard Time (PST): -8

     • Note: US UTC offset varies during Daylight Savings Time

   • Trigger At Local Time Hour: Set execution time in 1-hour intervals (e.g., 6, 12, 24)

4. Use the Conditions tab to configure action sequences:

   a. Click Add Condition to configure settings:

   • Condition Name: Use descriptive names (e.g., "Sync Okta Identities" or "Azure Helpdesk Role")

   • Continue Actions if Any Error: Enable to continue workflow despite failures

   • Condition Type: Choose between immediate execution or SCIM filter-based conditions

   b. Configure Actions:

   • Choose Action Type:

     • New: Create an action with custom settings

     • Existing: Select a previously created action

   • Use Edit Action > Conditions for nested conditions

   c. Add additional conditions as needed

5. Save changes:

   • Click Save in the left sidebar for workflow changes

   • Click Save on the policy details page to commit all changes

Common Transformers

Common transformers define one or more rules to apply when synchronizing a target identity's attributes. Use them in situations where you want to create or update attributes using the same conventions across multiple sync or de-de-provision actions.

To add a common transformer:

1. Edit a policy and open the Common Transformers tab

2. Give the transformer a name and description, and specify the data source it applies to.

3. Choose the target Entity Type.

4. Click Add Attribute to specify an attribute and the value format.

5. Optionally, enable Continuous Sync to keep the target entity up-to-date with values from the source of truth.

6. Save the transformer.

Notifications

Events and Actions

Events and Actions: Lifecycle Management Actions can result in multiple events, each associated with a specific operation in a target application. An action might cause more than one event. For example, the "De-provision Identity" action for Active Directory leaver flows could result in a combination of events:

• "Disable Identity" (set account to inactive)

• "Sync Identity" (update DN and primary group DN)

• "Remove Relationship" (remove existing profiles) events. You can review individual events and their status using the Activity Log.

Monitor individual events and their status using the Activity Log.

Notification Configuration

When events occur during the execution of a policy’s workflow, notifications can be triggered by Lifecycle Management as a means to inform stakeholders or integrate with external systems, such as triggering external automation. These notifications are configured in policies and Lifecycle Management supports email- and webhook-based notifications.

Use the Notifications tab when editing a policy to add and manage notifications at the policy level:

1. Choose the notification type (Email or Webhook)

2. Choose the event to trigger notifications:

   • Create Identity

   • Sync Identity

   • Add Relationship

   • Remove Relationship

   • Create Email

   • Change Password

   • Delete Identity

   • Disable Identity

   • Manage Relationships

   • Write Back Email

3. Choose the status to trigger notifications (when an event is successful, or it fails).

4. Customize the email or webhook settings:

   • Webhook:

     • Webhook URL: The endpoint configured to receive the webhook payload.

     • Webhook Auth Header: if the webhook listener requires authentication, provide it here.

   • Email:

     • Emails: Recipients added to the to field.

     • Extra Email Fields (Optional): Recipients added to the cc field.

5. Save the changes.

Note that emails and webhooks can also be configured on a per-action basis.

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.

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.

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.

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.

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.

Getting Started

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:

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:

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

This document provides an introduction to integrations supported by Veza Lifecycle Management (LCM), including their capabilities and supported actions. 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 Suppported Integrations

For any Veza-supported application not listed above, please reach out to 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.

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

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

Supported Capabilities

Lifecycle Actions Supported

Create Email

Supports the creation of email accounts for users within Exchange Server.

• Entity Type: Exchange Server Users

• Attributes Available for Configuration:

  • Identity (Required)

  • Alias (Optional)

Example Use Cases:

• Create email accounts for new employees joining the organization

• Assign email aliases to users to facilitate communication

Configuration Steps

1. Locate Exchange Management Shell Paths

1. Find the Exchange Management Shell shortcut in the Start Menu

2. Right-click > More > Open File Location
3. Right-click the shortcut icon > Properties
4. Copy the Target field value
5. Note the two important paths from the target:

   • PowerShell Path: (e.g., C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)

   • Remote Exchange Path: (e.g., C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1)

2. Create Application Pool in IIS

1. Open IIS Manager and create a new application pool
2. Name the application pool
3. Configure the application pool:

   • Right-click > Advanced Settings

   • Under Process Model, set the Identity

3. Configure IIS Application

1. Add the application to "Default Web Site"
2. Configure the application:

   • Set alias to "VezaProvisioner"

   • Select the application pool created above
3. Configure authentication:

   • Disable Anonymous Authentication

   • Enable Basic Authentication

4. Install Veza Provisioner

Install the VezaProvisioner.msi installer provided by Veza support on the Exchange Server. This component handles email address creation for users provisioned in Active Directory.

5. Configure Exchange Server Integration in Veza

1. Go to Configurations > Integrations

2. Click Add New and select Exchange Server

3. Complete the following fields:

   Field

   Description

   Insight Point

   Select if using an Insight Point to access Exchange Server

   Name

   Friendly name for the integration

   Instance URL

   https://<exchange_server_host>/VezaProvisioner

   Username

   Domain username with required Exchange permissions

   Password

   Password for the account

   PowerShell Path

   Path to PowerShell.exe noted in step 1

   Remote Exchange Path

   Path to RemoteExchange.ps1 noted in step 1

4. Enable Lifecycle Management by checking Enable Lifecycle Management

5. Save the configuration

6. Verify Configuration

After configuration, the Exchange Server integration will be available for use in Lifecycle Management policies, specifically for the Create Email action. This action can be used in workflows for new employee onboarding or other scenarios requiring email account creation.

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

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