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

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

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

• Manage Relationships

• Lifecycle Management Policies

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

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.

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

Overview

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

• Whether the profile can inherit entitlements from other profiles

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

• The maximum number of entitlements the profile can grant

• The specific integrations where entitlements can be granted

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

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

       • 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

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

The Veza integration for Salesforce enables automated user lifecycle management across your identity ecosystem. This integration allows security and IT teams to automate the provisioning, updating, and deprovisioning of Salesforce user accounts based on changes in an authoritative source (such as an HRIS system or another identity provider).

Key capabilities include:

• User Provisioning: Automatically create Salesforce user accounts with appropriate profiles and permissions

• Attribute Synchronization: Keep user details in sync across systems, ensuring data consistency

• Permission Management: Assign and remove permission sets and roles based on policies

• User Deprovisioning: Safely disable access when users leave the organization

The integration leverages the SCIM protocol for standardized identity management operations and uses Salesforce-specific APIs for permission management.

This document includes steps to enable the Salesforce integration for Lifecycle Management, along with details on supported actions and notes.

Prerequisites and Configuration

Before configuring the integration, ensure you have:

1. Administrative access in Veza to configure the integration

2. An existing Salesforce integration in Veza or add a new one

3. At least one successful extraction from your Salesforce integration

4. The appropriate permissions in Salesforce

5. Salesforce API v40 or later for user provisioning

Required Permissions

The Salesforce integration will need the following permissions:

• Assign Permission Sets: Enables assignment and removal of permission sets for users.

• Freeze Users: Enables freezing and unfreezing user accounts.

• Manage Internal Users: Required for user creation and updates.

• Manage IP Addresses: Required for managing trusted IP ranges if IP restrictions are used.

• Manage Login Access Policies: Required for configuring login access policies.

• Manage Password Policies: Required for setting and resetting passwords during user creation.

• Manage Profiles and Permission Sets: Required for permission set and profile assignment.

• Manage Roles: Required for role assignments and management.

• Manage Sharing: Required for managing sharing rules and access control.

• Manage Users: Essential for user lifecycle operations.

• Monitor Login History: Required for monitoring user logins.

• Reset User Passwords and Unlock Users: Required for account management.

• View All Profiles: Required to view profile information for all users.

• View All Users: Required to view all user information.

In Salesforce, you can add these permissions for the Veza connected app in the System Permissions section at the bottom of the Permission Set configuration page.

SCIM Requirements

Veza Lifecycle Management uses Salesforce SCIM APIs for identity provisioning operations. The SCIM protocol enables the automated exchange of user identity data between Veza and Salesforce. The permissions listed above provide the necessary access for SCIM functionality.

• The Connected App used for the integration must have OAuth scopes that include api and refresh_token permissions and a certificate for JWT-based authentication

• To make the required API calls, the integration requires a custom user profile in Salesforce with "API Enabled" permission

For additional details about Salesforce's SCIM implementation, refer to the Salesforce SCIM documentation.

Enabling the Integration

To enable the integration:

1. In Veza, go to the Integrations overview.

2. Search for or create a Salesforce integration.

   1. Ensure the integration permission set includes the required permissions.

3. Check the box to Enable usage for Lifecycle Management.

4. Save the configuration.

Configure the extraction schedule to ensure your Salesforce 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 Salesforce 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.

SCIM Implementation Details

Veza's Salesforce integration implements the SCIM 2.0 protocol to standardize identity management operations:

• Users are represented with standard SCIM core attributes plus Salesforce-specific Enterprise extensions

• The system uses email addresses as the primary key for user lookups

• Usernames cannot be changed after creation and must be unique within the Salesforce instance

• User profiles are managed through SCIM entitlements

• User roles are handled through SCIM roles endpoints

• User Deprovisioning is implemented as deactivation (setting active=false)

• Permission sets are assigned through Salesforce API calls after user creation

Supported Actions

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

Salesforce 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 Actions:

Sync Identities

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

• Usernames cannot be changed after creation.

• Email addresses must be unique.

• Required attributes must be present (Username, Email, FirstName, LastName).

• Passwords are set during user creation.

• Division and Department attributes are excluded during updates due to Salesforce API limitations.

• Salesforce does not support changing usernames after creation.

The following attributes can be synchronized:

Manage Relationships

The following relationship types are supported:

• Groups: Add and remove group memberships (only for groups with Group Type = Regular).

• Permission Sets: Add and remove permission set assignments.

• Permission Set Groups: Add and remove permission set group assignments.

• Profiles: Manage profile assignments.

• User Roles: Synchronize user role assignments.

Notes:

• Profile and role assignments are managed via SCIM and Salesforce APIs.

• When removing a profile assignment, users are assigned the "Minimum Access - Salesforce" profile by default. This profile must exist in your Salesforce instance for profile changes to work properly.

• Only Salesforce groups with the property Group Type = Regular can be used in Manage Relationships configurations.

• Groups of type RoleAndSubordinatesInternal are not supported but can be assigned through their corresponding roles.

• Direct creation of permission sets ("Create Entitlement" action) is not currently supported.

Deprovision Identity

When a user is deprovisioned:

• The user account is frozen or deactivated (Salesforce does not allow user deletion).

• Permission set assignments are removed.

• Attribute history is preserved for audit.

• The account can be reactivated if needed.

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

   • See for supported providers and steps to enable a Lifecycle Management data source

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.

See for available transformation functions.

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.

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 Supported Actions 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 Okta integration 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 Policies. 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 Actions:

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 Azure AD (Microsoft Entra ID) enables automated user provisioning, access management, and de-provisioning capabilities. This integration allows you to synchronize identity information, manage group memberships, assign licenses, and automate the user lifecycle from onboarding to offboarding.

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

Enabling Lifecycle Management for Azure

Prerequisites

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

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

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

4. The Azure integration will need the following additional Microsoft Graph API permissions:

   • Directory.ReadWrite.All - Required for creating, updating, and managing directory objects

   • Group.ReadWrite.All - Required for creating and managing groups

   • GroupMember.ReadWrite.All - Required for managing group memberships

   • User.EnableDisableAccount.All - Required for enabling/disabling user accounts

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create an Azure integration

3. Check the box to Enable usage for Lifecycle Management

4. For complete Azure integration setup instructions, including how to create an App Registration and grant permissions, please refer to the Azure Integration Guide

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

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

Azure AD 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 Actions:

Sync Identities

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

• Entity Types: Azure AD User

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

The following attributes can be synchronized:

Create Guest User Accounts

Creates guest user accounts in Azure AD by sending invitations:

• Required Attributes:

  • invited_user_email_address - Email address of the person to invite

  • invite_redirect_url - URL where the user is redirected after accepting the invitation

• Optional Attributes:

  • principal_name - User principal name (if not provided, generated from email)

  • display_name - Display name (if not provided, generated from email)

  • mail_nickname - Mail nickname (if not provided, generated from email)

  • Other standard user attributes as needed

Manage Relationships

Controls relationships between users and Azure AD entities:

• Supported Relationship Types:

  • Groups: Add or remove users from Azure AD groups

  • Roles: Assign or remove Azure AD roles

  • Licenses: Assign or remove license assignments

  • Distribution Lists: Manage Exchange Online distribution list memberships

• Assignee Types: Azure AD Users

• Supports Removing Relationships: Yes

Create Email

Creates or enables email functionality for users in Azure AD:

• Implementation: Assigns Exchange Online license to the user

• Requirements: Available Exchange Online license in your tenant

• Results: Email-enabled user account with Exchange Online capabilities

Create Entitlement

Creates new entitlements in Azure AD, including groups and distribution lists:

• Azure AD Group Creation:

  • Required Attributes: name

  • Optional Attributes:

    • mail_enabled - Whether the group is mail-enabled

    • is_security_group - Whether it's a security group

    • visibility - Privacy setting (Public, Private, HiddenMembership)

    • description - Group description

• Distribution Group Creation:

  • Required Attributes: name

  • Optional Attributes:

    • identity - Unique identifier

    • alias - Email alias

    • primary_smtp_address - Primary email address

    • group_type - Type of distribution group

Deprovision Identity

When a user is deprovisioned:

• Entity Type: Azure AD Users

• Remove All Relationships: Yes (Removes group memberships, role assignments, and license assignments)

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

• Additional Options:

  • User Logout - Force user to log out from all active sessions

  • Remove All Licenses - Remove all license assignments

  • Remove All Personal Devices - Remove device registrations

Disable Guest Accounts

Specifically handles deprovisioning of guest user accounts:

• Required Attributes:

  • invited_user_email_address - Email address of the guest user

• Optional Attributes:

  • display_name - Display name of the guest user

Custom Properties

Azure AD integration supports custom properties defined in your tenant. These can be configured in the integration settings and used in attribute transformers for Lifecycle Management actions.

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

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

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 section

API Access Notes

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

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

This guide explains how to configure identity override attributes in Lifecycle Management to address scenarios where user attributes at the source of identity are incorrect, slow to update, or temporarily need adjustment for policy execution.

Identity override attributes allow Lifecycle Management administrators to override the value of any user attribute set at the source of identity. These overrides take precedence over actual values during Lifecycle Management workflows.

Problem scenarios for attribute overrides

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

• Incorrect or slow-to-update attributes:

  • Employee termination: An employee has been terminated and needs immediate deprovisioning, but the termination status is not yet reflected at the source of identity

  • Role changes: An employee has immediately changed roles and needs new birthright access, but the role change and the new manager haven't been updated in the source system

  • Contract extensions: A contractor's end date has been extended, but the extension isn't reflected yet at the source of identity

  • Missing manager data: The source of identity is missing a manager value, but this information is required for downstream application provisioning

• Emergency access control:

  • Security incidents: Immediate access restrictions are needed before HR systems can be updated

  • Temporary access grants: Providing temporary access while permanent changes are processed

Before you start

Before you configure identity override attributes, verify that override values comply with organizational policies and data standards, and assess the downstream impact of attribute changes. Ensure:

• You have administrative access to Veza Lifecycle Management

• You understand which source identity attributes need to be overridden

• You have identified the specific identities requiring attribute overrides

• You understand that overrides only affect Lifecycle Management workflows, not Access Visibility

• You recognize that overrides should be used for exceptional cases, not routine operations

Configure identity override attributes

Veza supports overrides for various property types from the source of identity:

• Text properties (e.g., Department, Manager, Job Title)

• Date properties (e.g., Activated At, Hire Date, End Date)

• Numeric properties (e.g., Employee ID)

• Boolean properties (e.g., Active status, Enabled flags)

Create attribute overrides for individual identities

You can view, create, edit, and delete overrides from the identity details view.

1. Click Lifecycle Management in the main navigation, then select the Identities tab.

2. Locate the identity requiring an attribute override.

   2.1. Use the Search by name field to find the specific user

   2.2. Click on the identity name to show more information in the sidebar

   2.3 Click Details to open the expanded details view

3. Open the identity's Properties tab:

   3.1 In the identity detail view, click the Properties tab to view all available attributes from the source of identity.

   The Properties tab displays both original attribute values and any existing overrides.

4. Create a new attribute override:

   4.1. Find the attribute you want to override in the properties table

   4.2. Click the Actions menu (three dots) for that attribute

   4.3. Select Create Override from the dropdown menu

5. Set the override value in the Create Override dialog:

   5.1. Enter the desired override value in the Override Value field

   5.2. For date attributes, use the calendar picker to select the appropriate date and time

   5.3. For text attributes, type the new value directly

   5.5. Click Save to apply the override, or Cancel to discard changes

   The Create Override modal displays the attribute name and the current actual value for reference.

6. Verify the attribute override is active:

   • The Override column now shows "yes" for the modified attribute

   • The Override Value column displays your custom value

   • The override count updates in the Property Overrides filter (e.g., "1 Override")

7. View the override summary in the identity details Overview tab:

   7.1. Return to the Overview tab for the identity

   7.2. Check the Property Overrides section to see all configured overrides for the identity

   7.3. Each override displays the attribute name, override value, and actual value from the source

The identity details view provides visibility into both original and overridden values. A visual indicator will highlight any attributes with overrides:

1. Properties: Use this tab to show side-by-side comparisons of actual values from the source of identity and override values

2. Overview: This tab includes a consolidated view of all active overrides for an identity

Update existing overrides

To change the value of an attribute override:

1. Navigate to the identity's Properties tab. Access the same identity detail view where you created the override.

2. Locate the attribute with an active override. Find the attribute showing "yes" in the Override column.

3. Edit the override value.

   3.1. Click the Actions menu (three dots) for the overridden attribute

   3.2. Select Edit Override from the dropdown menu

3.3. Modify the Override Value in the dialog 3.4. Click Save to apply the changes

Cancel attribute value overrides

To remove an override:

1. Access the identity's Properties tab. Navigate to the identity detail view with active overrides.

2. Identify the override to remove. Locate the attribute with "yes" in the Override column.

3. Clear the override.

   3.1. Click the Actions menu (three dots) for the overridden attribute

   3.2. Select Clear Override from the dropdown menu

   3.3. Confirm the action when prompted

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

Important considerations

Override scope and limitations

The current implementation supports overrides at the individual identity level. Note that any attribute overrides are not reflected in the Veza Access Graph.

• Lifecycle Management only: Attribute overrides affect only Lifecycle Management workflows and policy execution

• Access Visibility unchanged: The authorization graph and Access Visibility features continue to use the actual source of identity values

• Source system independence: Overrides do not modify data in the originating identity providers or HR systems

Operational best practices

You should typically use overrides as temporary measures while addressing root causes in source systems. Maintain clear records of why each override was implemented and the business justification.

Consider the following best practices when implementing attribute overrides:

• Regular review process: Establish periodic audits of active overrides to ensure they're still necessary

• Monitor policy impact: Review workflow execution logs to confirm that overrides produce expected policy outcomes. You can review the identity details Activity tab and Lifecycle Management Activity Logs to ensure that override values are applied as expected during provisioning, deprovisioning, and other lifecycle actions.

• Emergency response procedures: Establish clear protocols for when and how to use overrides in approved scenarios.

• Change management coordination: Communicate with HR and identity provider teams when overrides are needed.

See also

• Lifecycle Management Policies

• Lifecycle Management Overview

• Access Profiles

• Conditions and Actions

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