Lifecycle Management FAQ

Frequently asked questions about Veza's Lifecycle Management for automated identity and access governance

This document addresses common questions about Lifecycle Management (LCM) for automated identity and birthright access governance across systems and applications.

Overview

The questions in this document are designed to introduce key concepts and address common questions that often arise during deployments. Please contact your support team with additional questions and feedback. Note that specific functionality may depend on the features and integrations enabled in your environment.

Learning more

Your Lifecycle Management configuration can be straightforward or complex, depending on your organization's needs. To learn more about general implementation patterns, see Lifecycle Management with Workday, Okta, and Active Directory and Implementation and Core Concepts.

Dry Run Testing

Can I test policy changes before making them live?

Yes, you can test policy changes safely using Dry Run simulations before deployment. Testing best practices include:

Draft Version Testing: Creating a draft version of your policy enables dry runs against the contained workflows and trigger conditions.
Policy DRY_RUN State: Setting the entire policy to DRY_RUN state enables simulations during regular processing cycles.
Sample Identity Testing: You can create representative identities to validate behavior across different user types before running workflows in production environments.

Best practices for dry run testing:

Test with identities representing each employee type (contractors, FTEs, managers)
Validate both positive cases (access granted) and negative cases (access denied)
Review the complete dry-run messages to understand workflow logic (via API or GUI)
Document expected vs. actual results before full deployment

Always run tests before changing a policy from DRY_RUN to RUNNING state.

Can Dry Run simulations be performed against an identity, a workflow, or all workflows in a policy?

Dry Runs are performed at the identity level and automatically evaluate against all workflows in the selected policy.

Dry Runs test how workflows within a policy will apply to individuals in your sources of identity. The test includes:

Testing specific users (existing or hypothetical) against configured conditions and actions
Evaluating the identity against every workflow within the LCM Policy version

Starting a Dry Run

You can initiate a dry run in two ways:

From a Lifecycle Management Policy: When editing a policy, open the Dry Run tool to preview changes for any identity:

Go to Lifecycle Management > Policies
Click a Policy to view its details
Click Dry Run Policy at the top right
Choose the identity and policy to test workflows
Select one or more attributes to sync. You can modify attributes to simulate potential changes
Click Show Results
Review the results:
- Check the Workflows Run section to see which workflows were triggered
- Check the Potential Changes section to see all job requests that would be generated (e.g., edits to user attributes, adding/removing access profiles)

From Identity Details: You can start a Dry Run when viewing details for any account on the Identities page:

Go to Lifecycle Management > Identities
Search for an identity and click to view its details.
Expand the Actions menu at the top right and click Policy Dry Run.
Select a policy, customize entity attributes, and click Show Results.

This simulates lifecycle events (new hire, modification, termination) modeled by workflows in the policy. The response includes:

Matched Workflows: Which workflows triggered and why
Planned Actions: What provisioning/deprovisioning would occur
Access Profiles: Which access profiles would be assigned or removed

For API documentation, see Run Dry Run on Identity. The API endpoint is PolicyIdentityDryRun in the lifecycle management service.

What happens during a Dry Run simulation?

During a Dry Run test, LCM simulates the complete policy execution without making actual changes. The Dry Run process includes steps for:

Identity Evaluation: The specified identity is evaluated against all policy conditions
Workflow Matching: Each workflow's trigger conditions are checked
Action Simulation: Actions that would execute are identified, but not performed
Access Profile Assignment: Determines which access profiles would be assigned
Result Generation: Comprehensive report generated with no system changes

Use this option for safe testing without making changes and troubleshooting when certain actions aren't triggering for specific users.

Policy Configuration

What is the "Skip if action has already been run" option, and when should I use it?

The "Skip if action has already been run" option (also called "Run Once") is a safety mechanism that prevents the same action from being executed multiple times for the same identity, even if the workflow triggers again.

When enabled for an action:

LCM tracks whether the action has already been successfully executed for each identity
Before executing, it checks the identity's action history
If already completed successfully, the action is skipped
The rest of the workflow continues normally

Enable "Run Once" for one-time actions that should not be repeated once successful. Common examples include:

Create Email actions to prevent creating duplicate email accounts
Welcome Emails to avoid multiple messages on user creation
Initial Password Setup to ensure a password is generated only once
One-time Provisioning Actions that create resources that shouldn't be duplicated
Notifications to prevent duplicate notifications for the same event

You can disable the “Run Once” option for naturally repeatable actions:

Sync Identity: Typically safe to update attributes multiple times
Manage Relationships: Adding/removing group memberships handles duplicates
Deprovision Identity: Safe to remove access multiple times

For example, when a user changes departments, the desired outcome when triggering a workflow will be:

First run: "Send manager notification" action executes
User's location changes (triggering the same workflow)
Second run: "Send manager notification" is skipped (already ran once)
Other actions like "Update group membership" still execute

The "Run Once" option is ideal for actions that could cause problems if repeated, such as sending notifications or creating unique resources. Each identity's history is tracked separately, and only successful completions prevent re-execution. Failed actions will retry on the next workflow run regardless of any system restarts.

Troubleshooting "Skip if action has already been run" Actions

If an action with "Skip if action has already been run" enabled needs to be re-executed (e.g., after fixing an error):

The action history must be cleared via API
Failed attempts don't count as "run once" - they will retry
Check the identity's action history in the audit log

Workflows within a policy can have different priority levels. Higher priority workflows execute first when multiple workflows trigger for the same identity.

How do I enable a new lifecycle management policy?

Creating a policy involves configuring your source(s) of identity, workflows, and actions to automate lifecycle events:

Create Policy: Go to Lifecycle Management > Policies > Create Policy
Configure Source: Select your HR system or IDP as the data source
Add Workflows: Define triggers for Joiner, Mover, and Leaver scenarios
Configure Actions: Set up provisioning, deprovisioning, and access assignments
Test and Activate:
- Run dry-runs to test the policy configuration
- Click Publish to save the policy (it will be in Initial state)
- Click the Actions menu (⋮) and select Start to activate the policy (Running state)

For detailed step-by-step instructions, see Lifecycle Management Policies

What is the Continuous Sync option, and why should I use it?

Continuous Sync keeps a provisioned user's source attributes automatically updated in target systems after initial provisioning. In an LCM Policy, Continuous Sync is the ongoing synchronization of user attributes (email, department, manager, role, etc.) from identity sources into the target provisioning system, rather than just syncing once at provisioning time.

The term "Continuous Sync" describes the concept in Lifecycle Management. In the Veza UI, you will configure this at the attribute or action level with options:

Action level: "Update active users" (toggle on Sync Identity actions)
Attribute level: "Set for new users only" or "Set for new and existing users" (radio buttons when configuring individual attributes)

For complete configuration details, see Attribute Synchronization.

Use Continuous Sync for the following reasons:

Keeps downstream systems current - If a user's details change (e.g., title, manager assignment), the updated values propagate automatically.
Reduces drift - Avoids stale, inconsistent, or obsolete attribute values that could block access governance or impact compliance.
Supports policy logic - Sync-updated attributes can be used in dynamic policy conditions—e.g., triggering access revocation when department switches.

Configuration Levels

Continuous Sync 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

You may not want to enable Continuous Sync at the Attribute level when there is a change in the user principal name, such as a change in marital status or legal name correction.

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:

Enable Continuous Sync on the workflow to monitor for changes
Enable Continuous Sync on the sync action to allow updates
Enable Continuous Sync on the department attribute transformer

Recommended Settings

Enable Continuous Sync for attributes that change during employment:

First Name/Surname
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.

Why are secondary sources of identity optional if an admin can add multiple primary sources?

Secondary sources of identity are not redundant, despite the availability of multiple primary sources. They serve fundamentally different purposes:

Primary Sources of Identity (SOI):

Must all be of the same entity type (e.g., all Worker entities from Workday).
Create the core identity records that drive lifecycle management workflows.
All primary sources are treated as authoritative for identity creation.
Changes in any primary source trigger lifecycle workflows.

Secondary Sources of Identity:

Can be of different entity types than the primary source (e.g., HRIS Employee records enriching Workday Workers).
Primarily used for enrichment rather than identity creation.
Support two distinct operational modes via the only_enrich_existing flag:
- Enrichment mode (only_enrich_existing = true): Only adds attributes to existing identities created from primary sources.
- Hybrid mode (only_enrich_existing = false): Can create new Policy Identities if they don't exist in primary sources.

Secondary sources of identity provide flexibility in scenarios that require:

Data Enrichment from Non-Identity Sources: Organizations may need data from systems that shouldn't be authoritative for the identity lifecycle. Secondary sources support scenarios where core identities originate from HR (primary), and additional attributes come from departmental systems (secondary). Not all employees may exist in all systems. For instance:

HRIS system (primary) defines who exists in the organization.
A secondary system provides office location or manager metadata.
The secondary system shouldn't create/delete identities but should enrich them.

Cross-System Correlation: Secondary sources create attribute mappings to link records across systems using custom correlation logic. This supports multiple matching strategies:

Exact match on identifier (e.g., employee_id = worker_id)
Email-based correlation
Composite key matching (multiple attributes)
Custom correlation expressions
For example, correlating employee_id from an HRIS system with a worker_id in Workday, or matching users across systems based on email addresses.

Access Profiles

What are Access Profiles, and how do they work with LCM?

Access Profiles are collections of entitlements (including groups, roles, or permissions) that can be automatically assigned to users based on their attributes, like department, role, or location. Access Profiles serve two key functions in Lifecycle Management:

Birthright Access: Automatically assigned through policy workflows during joiner/mover/leaver events
Just-in-Time (JIT) Access: Available for request through Access Requests, with approvals handled by Access Requests and provisioning managed by LCM policy

The Access Profile Type determines its behavior and capabilities. When using the DEFAULT template, Veza provides five out-of-the-box (OOTB) Access Profile Types:

Business Role: Models your organizational structure (e.g., "Sales Team", "Engineering Managers") and inherits access from other profiles without direct entitlements
Entitlement: Manages single entitlements within a specific datasource (e.g., a specific AD group or Okta role)
Application: Grants application-level access without specific entitlements (e.g., basic app login rights)
Application Entitlements: Bundles multiple entitlements from a single application (e.g., multiple Salesforce profiles and permission sets)
Multi Application Entitlements: Combines entitlements across multiple applications (e.g., a developer bundle with GitHub, Jira, and AWS access)

Organizations can also create custom Access Profile Types to meet specific requirements or use alternative templates like SAILPOINT (which creates Profile and Business Role types) or HIERARCHICAL (which creates a single flexible type supporting both direct and inherited access).

How Access Profiles Work in Different Scenarios

Birthright Provisioning: Access Profiles are assigned through the Manage Relationships action in policy workflows, automatically granting appropriate access when users join, move within, or leave the organization.

Access Requests (Non-Birthright): Users can request Access Profiles through the Access Request system. While the request and approval process is handled by Access Requests, the actual provisioning and lifecycle of granted access is managed through LCM policy, ensuring consistent governance across all access types.

For configuration and best practices, see Access Profiles and Access Profile Types

Safety and Limits

What safety mechanisms prevent unintended mass changes?

Lifecycle Management supports safety limits to prevent accidental mass changes to identities. Policies can be configured to halt if the changes would impact more than a configured threshold of identities. When enabled, Veza calculates potential impact before processing the policy. If limits are exceeded, processing stops, a warning notification appears, and manual intervention is required.

Safety limits use count-based thresholds (e.g., no more than 100 identities) to control the maximum number of identities that can be affected in a single processing cycle.

For example, if you have 1,000 users in your organization and set a safety limit of 100 identities:

Veza will halt processing if more than 100 users would be affected
You will receive a warning notification, prompting review of the changes
You must then either adjust the policy or explicitly allow processing to continue

Safety limits are critical for production environments. Never proceed in re-enabling a policy without careful consideration. Safety Limits can be overridden with explicit API parameters.

Recovery Options

When a safety limit is triggered:

Review the warning details in the policy event log
Run dry-runs to understand the impact on affected identities
If changes are expected (e.g., bulk onboarding):
- Temporarily increase limits via API
- Process with disregard_change_limit=true parameter
- Reset limits after processing
If changes are unexpected:
- Check source system for data quality issues
- Review recent policy configuration changes
- Validate workflow trigger conditions

Notifications

When should I use policy-level notifications vs action-level notifications?

Lifecycle Management supports notifications at two distinct levels: policy-level (event-based) and action-level (per-action).

The key difference is the amount of context available. Policy-level notifications provide rich entity details suitable for stakeholder communications, while action-level notifications offer only basic action metadata for operational monitoring.

The levels of notifications you configure should be based on who needs to be informed and what information they require.

Feature

Policy-Level

Action-Level

Triggers on

Lifecycle events (CREATE_IDENTITY, ADD_RELATIONSHIP, etc.)

Individual action success or failure

Available data

Entity details (names, emails, attributes)

Action metadata (name, type, status) only

Configuration

Policy Settings > Notifications

Edit Action > Action Notification Settings

Scope

All workflows in the policy

Specific action instance

Best for

User and stakeholder communications

Simple operational confirmations

Policy-Level Notifications

Policy-level notifications trigger when specific lifecycle events occur, such as creating an identity, syncing attributes, or managing access relationships.

Because these notifications are tied to events rather than individual actions, they have access to full entity context including user attributes, relationship details, and outcome information. This makes them ideal for communications where recipients need to understand what changed and for whom.

These notifications support dynamic recipient selection based on user attributes (such as sending to a user's personal email or their manager's email) and include rich placeholder data. Entity information like {{ENTITY_NAME}}, {{LOGIN_NAME}}, and {{EMAIL}} allow you to personalize messages with specific details about the identity being managed. For relationship events, placeholders like {{RELATIONSHIP_ENTITY_NAME}} provide context about access grants or revocations. The full list of available placeholders is documented in Notification Templates.

Common scenarios for policy-level notifications:

When notifying end-users about account provisioning, policy-level notifications can inform users their account is ready and provide their username for first login. For example: "Hello {{ENTITY_NAME}}, your Active Directory account has been created. Your username is {{LOGIN_NAME}}."

For access change communications, these notifications can explain what access was granted or revoked with full context. For instance, you might notify a user: "You have been added to the {{RELATIONSHIP_ENTITY_NAME}} group" when relationships are managed.

IT operations teams benefit from policy-level notifications that aggregate activity across all workflows, providing visibility into identity lifecycle events with complete context for audit and troubleshooting purposes.

See Policy Notifications for configuration instructions.

Action-Level Notifications

Action-level notifications trigger when a specific workflow action completes, whether successfully or with errors. Unlike policy-level notifications, these provide only basic action metadata—the action name, type (such as SYNC_IDENTITIES or MANAGE_RELATIONSHIPS), success/failure status, and an internal job identifier. They do not include any information about the entities being acted upon, making them unsuitable for communications requiring user-specific details.

The primary use case for action-level notifications is operational monitoring where you need simple confirmation that a particular action completed. For example, alerting an operations team that a high-risk provisioning action finished, or confirming a critical workflow step succeeded before proceeding to dependent processes. These notifications work well when different actions in various workflows require different handling, and you need granular control over which specific action executions trigger alerts.

See Send Notification Action for configuration details.

Example: Notifying Users When AD Accounts Are Created

Scenario: As an admin, you want to notify end-users when their Active Directory account is created during onboarding.

Recommended approach: Use policy-level notifications configured for the CREATE_IDENTITY or SYNC_IDENTITY event. Navigate to Policy Settings > Notifications and create a notification with:

Event Type: Sync Identity (or Create Identity)
Status: Successful
Recipients From User's Attributes: Select the user's email field (such as personal_email)
Custom Template: "Hello {{ENTITY_NAME}}, your Active Directory account has been created. Your username is {{LOGIN_NAME}}. Please log in at your earliest convenience."

This configuration ensures users receive personalized notifications with their specific account details immediately upon provisioning.

Understanding Notification Limitations

Password placeholder availability: The {{LOGIN_PASSWORD}} placeholder is only available for CHANGE_PASSWORD and RESET_PASSWORD event types, not for CREATE_IDENTITY or SYNC_IDENTITY events. If you need to communicate passwords during initial account creation, configure a separate Reset Password action in your workflow after the account is created, then notify users via the RESET_PASSWORD event.

Action-level data constraints: Action-level notifications cannot access entity-specific information such as usernames, email addresses, departments, or any user attributes. They only provide action metadata (name, type, success/failure status). For any communication requiring user details or context, use policy-level event notifications instead.

Event types and placeholders: Different event types support different placeholder sets. For example, relationship events include {{RELATIONSHIP_ENTITY_NAME}} while identity creation events include {{LOGIN_NAME}}. Review the complete placeholder reference in Notification Templates when designing your notification templates.

Choosing the Right Level

For user-facing notifications and stakeholder communications where context matters, use policy-level notifications. These provide the entity details and user attributes needed for meaningful, personalized alerts that help users understand what changed and why.

For simple operational confirmations where you only need to know an action completed (without needing details about which user or entity was involved), use action-level notifications. These are appropriate for workflow orchestration or basic monitoring where action metadata suffices.

When in doubt, start with policy-level notifications—they provide more information and flexibility for most common notification scenarios.

Access Request Notifications

Do administrators need to configure notifications for Access Request events?

Yes, administrators must explicitly configure notifications for Access Request events. Notifications can be configured for six event types (created, action run, completed, failed, state changed, approver assigned), with recipients selected from five categories: Approvers, Creator, Beneficiary, Watchers, or specific email addresses.

Behavior Change (August 2025): Previously, notifications were automatically sent to all recipient types for all events. The default was removed for better control. Existing customers had settings automatically migrated to match the old behavior.

Configure notifications through Lifecycle Management > Settings > Access Request Settings > Notifications, or via the Access Request Settings API. Note that there is no "all admins" option—administrators receive notifications only when explicitly configured as approvers, creators, watchers, or listed in other_emails.

Without notification configuration, users and approvers won't receive alerts about access request activities.

How do I control or stop Access Request notifications?

Access Request notifications are sent to five recipient categories: Approvers, Creator, Beneficiary, Watchers, and other_emails (specific addresses). Administrators receive notifications only when explicitly configured in one of these roles—there is no "all admins" setting.

Common issue: If you're receiving unwanted notifications, you're likely configured as a default approver for Access Requests with to_approvers=true enabled. For customers migrated from pre-August 2025, all recipient types are enabled by default.

Solutions:

Remove your role: Stop being an approver, creator, or watcher for requests
Modify settings: Disable specific recipient groups (e.g., to_approvers=false) in Lifecycle Management > Settings > Access Request Settings > Notifications
Disable events: Turn off entire event types if not needed

For programmatic configuration, contact your Customer Success Manager or Veza support.

Does the notification body support rich text HTML?

Yes, notification templates fully support HTML and CSS. You can use standard HTML markup, inline styles, images, and links in all Lifecycle Management and Access Request notification templates.

Key Capabilities

Standard HTML tags (<html>, <body>, <br>, <div>, <p>, etc.)
CSS styling (inline or embedded)
Images (embedded attachments or external URLs)
Links and formatting
Custom branding and layouts

Template Management

Templates are currently managed via the Notification Templates API
All built-in templates use HTML structure
Support for small image attachments (under 64kb, base64-encoded)
External image linking for high-resolution content

For complete setup instructions, HTML examples, default templates, placeholder reference, and detailed formatting guidance, see Notification Templates for Lifecycle Management

Data Processing and Extraction

When does LCM evaluate identities for CSV/OAA data sources?

LCM processes identities from CSV and OAA-based data sources only when specific events occur, unlike native integrations that can pull data on demand.

Trigger Events for Identity Processing

For CSV and OAA data sources, extraction and identity evaluation occur when:

New Data Push - A new CSV file is uploaded or an OAA payload is pushed
Policy Configuration Changes - Any policy update forces a re-extraction
Manual Extraction - LCM explicitly queues an extraction job

Key Behaviors

No Automatic Refresh: CSV/OAA sources don't automatically fetch new data - they only process what was last pushed
Re-extraction Uses Same Data: If extraction is triggered without a new push, it re-processes the same payload
Policy Updates Trigger Processing: Changes to policy configuration (e.g., UID mapping, workflow conditions) will force re-extraction of existing data

CSV-Specific Details

CSV files are converted to OAA payloads upon upload
The original CSV is not stored; only the OAA transformation is retained
Re-extraction processes the stored OAA payload, not the original CSV

Common scenarios when working with CSV Uploads:

Daily CSV Upload:

New file uploaded → Extraction triggered → Identities processed
Workflows evaluate all identities based on the "Sync on changes only" setting

No New Upload for 7 Days:

No extraction occurs automatically
Existing data is NOT re-evaluated unless:
- Policy is modified
- Manual extraction is triggered

Policy Configuration Modified:

Policy change → Forced extraction of existing data
All identities re-evaluated with a new configuration
Can trigger workflows even without data changes

Important Considerations

Unexpected Re-processing: If workflows unexpectedly re-trigger for all users without a new CSV upload, check if:

Someone modified the policy configuration
UID mapping was changed
Workflow conditions were updated

These changes trigger re-extraction of the datasource and can cause all identities to be re-evaluated.

"Sync on changes only" Setting: When enabled, only identities with changed attributes or newly matching trigger conditions will have workflows executed, even during re-extraction.

CSV Upload and Transformations

Can I transform CSV data during upload for LCM?

Yes, Veza supports data transformations when uploading CSV files for HRIS and application data sources. This allows you to manipulate and format data during the upload process without preprocessing.

Supported Transformations

Transformations can be applied to CSV columns during mapping configuration:

String Operations: Concatenation, splitting, case conversion
Data Formatting: Date formatting, number formatting
Conditional Logic: If/then conditions based on column values
Template Mappings: Create complex attribute values from multiple columns

Use Cases

Combine Multiple Columns: Create full names from first/last name columns
Extract Data: Gather domains from email address values
Format Dates: Convert date formats to match target system requirements
Apply Business Logic: Set department codes based on location values
Generate IDs: Create unique identifiers from existing data

Example Transformations

Concatenate columns:

{{FirstName}} {{LastName}}

Extract email domain:

SPLIT(Email, "@")[1]

Pad employee ID with zeros:

LEFT_PAD({{employee_id}}, "0", 6)

Important notes:

Conditional logic is not supported: CSV transformations do not support IF statements or conditional expressions
CSV headers are automatically converted to lowercase, with underscores (e.g., "First Name" becomes "first_name")
Use {{column_name}} syntax to reference CSV columns in attribute transformations within a Lifecycle Management Policy.

Technical Implementation Note

When you upload a CSV file:

The CSV is immediately converted to OAA (Open Authorization API) format
Only the OAA payload is stored, not the original CSV
Any re-extraction uses this stored OAA payload
This ensures consistent data processing across all extraction cycles

Transformations are applied during the data extraction process and don't modify your original CSV file. The transformed values are what LCM uses for identity processing and provisioning.

CSV transformations have different capabilities than full LCM transformers - they support basic string operations and functions but not conditional logic or complex expressions.

Integrations

Does Veza support custom Active Directory attributes and moving users between organizational units (OU)?

Yes, Lifecycle Management fully supports both custom Active Directory attributes and moving users between organizational units.

Custom Attributes: You can synchronize custom AD attributes (like hrdivisionID, cost center, or other organizational data) from your source of identity. First, add custom properties in your AD integration configuration (in the Custom Properties step of the integration wizard), then map them in your LCM policy's Sync Identity action using attribute transformers. After enabling custom attributes for the integration, they can be set for new and existing users just as standard AD attributes.

Moving Between OUs: You can move users between organizational units by modifying the user's distinguishedName attribute in a Sync Identity action. For example, use CN={{login_name}},OU=Disabled Users,DC=company,DC=com to move terminated employees to a disabled users OU, or dynamically construct paths like CN={{login_name}},OU={{department}},OU=Users,DC=company,DC=com for department-based placement. This is useful for mover and leaver scenarios where users need to be relocated based on employment status or organizational changes.

For configuration details, supported attributes, and setup instructions, see [Active Directory Lifecycle Management](integrations/active-directory.md).

For details on configuring LCM integrations, including setup instructions, extraction requirements, and supported capabilities, see Lifecycle Management Integrations overview.

What is the difference between sources of identity and target applications in Veza Lifecycle Management?

There are two different types of integrations supported by Lifecycle Management:

Source of Identity (SOI): These are authoritative systems that provide definitive information about user identities and their status within an organization. Common examples include Human Resource Information Systems (HRIS), corporate directories, and Identity Providers (IdPs). While Veza typically does not require write permissions to these sources, some can also serve as provisioning targets and support write-back of newly created user attributes, such as an email address.
Target Applications: These are the applications, platforms, and systems where Veza can programmatically provision and deprovision user access. This includes a wide range of systems from cloud infrastructure (AWS, Azure) and databases (Snowflake, MySQL) to SaaS applications (Salesforce, Atlassian Cloud).

Do target applications have special integration requirements?

Veza provides comprehensive coverage for target applications through a multi-faceted approach:

Native Integrations: Veza offers native, full CRUD-based provisioning and deprovisioning for numerous applications and platforms, including IdPs, directories, cloud platforms, business and productivity applications, databases, developer platforms, and more. These integrations typically provide deeper control over entitlement management and support user lifecycle actions (onboarding/offboarding) beyond basic account creation.
SCIM Support: Lifecycle Management supports any application that supports SCIM provisioning standards as target applications. You can enable Lifecycle Management for compatible targets using the generic SCIM Integration
Open Authorization API (OAA): Custom Application Templates and custom REST API actions enable provisioning and deprovisioning for the long tail of custom, legacy, and homegrown applications.

Any non-SCIM application that offers a suitable interface for user provisioning and deprovisioning can be supported. Customers, partners, or Veza can easily develop integrations with custom applications.

What Source of Identity (SOI) systems are supported?

Veza LCM supports a variety of Source of Identity systems to serve as authoritative sources for user identity information.

Built-in SOI Systems include:

Beeline - Shift-based workforce management system
Coupa CCW - Cloud-based business spend management platform
Custom IDP - Generic identity provider integration for custom authentication systems
Custom HRIS (OAA) - Custom HR systems using Open Authorization API (OAA) templates
HiBob - Modern HR platform for businesses
Ivanti Neurons HR - HR platform for onboarding/offboarding and self-service
Okta - Cloud-based identity and access management service
Oracle HCM - Human Capital Management cloud solution
Workday - Cloud-based human capital management platform

CSV Upload and Open Authorization API templates provide an extensible framework for adding custom identity providers or HRIS platforms.

Custom OAA Integration - Any system can be configured as an SOI through the Open Authorization API
Custom Principal - Support for non-traditional identity sources

For integration setup for each target system, see the LCM Integrations Guide

Which SOI systems support email writeback?

Email writeback capability allows LCM to update the Source of Identity with newly created email addresses during provisioning workflows.

Systems Supporting Email Writeback

Currently, only a limited subset of integrations support email writeback actions:

Oracle HCM
Workday

How Email Writeback Works

LCM creates an email account in the target system (e.g., Exchange, Azure)
The newly created email address is written back to the user's record in the SOI
This ensures the SOI remains the authoritative source with current email information

Email writeback requires write permissions to the Source of Identity system, which may require additional configuration and security considerations. Refer to the specific integration documentation for setup requirements.

For detailed configuration instructions, see the integration-specific documentation in the LCM Integrations.

What target systems are supported natively and via SCIM?

Veza LCM supports provisioning across target systems through native integrations and SCIM protocol compatibility.

Supported Categories

Native Integrations (Full lifecycle support):

Identity Providers: Okta, Azure AD, Active Directory, AWS SSO
Collaboration: Google Workspace, GitHub, Exchange
Business Apps: Salesforce, ServiceNow, Workday, SAP ECC
Data Platforms: Snowflake, Veza Platform

SCIM 2.0 Support:

Generic SCIM (any compliant system)
Includes Atlassian Cloud, Oracle Fusion Cloud, and SwiftConnect

The entire Veza application catalog can potentially be LCM-enabled. Contact your Customer Success Manager to discuss enabling specific applications.

For all validated integrations and their capabilities, see LCM Integrations.

Advanced Configuration

What optional features can be enabled for LCM?

Lifecycle Management includes core workflow capabilities, with additional features available depending on your configuration needs. Some features that were previously gated are now available by default, while others require configuration or enablement.

Capability

What It Enables

Availability

Password Reset Workflows

Automatically reset passwords during user lifecycle events (termination, role changes)

Available by default

Automated Access Reviews

Trigger compliance access reviews automatically based on user changes

Available by default

Multiple Identity Sources

Use multiple HR systems or identity providers with priority handling

Available by default

Access Request & Approvals

Enables users to request access with automated approval workflows and provisioning

Requires configuration - contact your Customer Success Manager

Send REST Request Action

Custom REST API action for provisioning workflows to integrate with external systems and custom applications

Requires feature flag UI_LCM_SEND_REST_PAYLOAD_ACTION

Enhanced Dashboard View

Consolidated overview dashboard showing policies, activity, and integration status at a glance

Available upon request

Policy JSON Viewer

View and export full policy configurations in JSON format for debugging and technical support

Available upon request for advanced users

Features marked "Available by default" should appear automatically in LCM configurations. Other features may require additional setup or enablement. Contact your Customer Success Manager to discuss configuration options.

Are password reset and access review actions available by default?

Yes, the Reset Password and Create Access Review workflow actions are now generally available as standard LCM functionality. These action types appear as available options when configuring workflow actions in LCM policies.

Additionally, Secondary Sources of Identity are also now generally available, allowing you to configure secondary identity sources in policies without requiring special enablement.

These features were previously gated behind feature flags (LCM_RESET_PASSWORD_ACTION, LCM_CREATE_ACCESS_REVIEW_ACTION, and UI_LCM_POLICY_SECONDARY) but are now standard functionality available to all tenants.

How does Veza decide which identity source attributes to display when both primary and secondary sources exist?

When a policy identity has both primary and secondary sources, Veza determines which source's attributes to display in the Identities table based on the active status of each source. The "active" status is determined by the is_active field in each source of identity, which typically represents employment or account status (e.g., an active employee in Workday, an active contractor in a secondary system).

Default behavior (without feature flag):

Always displays the primary source attributes if a primary source exists
Only displays secondary source attributes if no primary source exists

Enhanced behavior (with LCM_PREFER_ACTIVE_SOI_IN_IDENTITY_TABLE feature flag):

Primary Source Status

Secondary Source Status

Displayed Attributes Source

Active

Any

Primary source

Inactive

Active

Secondary source

Active

Primary source (default)

Inactive

Primary source (default)

This prioritization ensures the Identities table reflects the most current source of truth, which is particularly useful in scenarios where:

A user's primary identity becomes inactive (e.g., employee terminated in Workday, is_active=false)
The secondary identity source remains active (e.g., contractor account still active in secondary system, is_active=true)
You need visibility into which system currently maintains active identity information

Example scenario: An employee terminates from their full-time position (primary Workday identity becomes is_active=false) but continues as a contractor (secondary source remains is_active=true). With the feature flag enabled, the Identities table displays attributes from the contractor system, reflecting their current active status.

This feature requires the LCM_PREFER_ACTIVE_SOI_IN_IDENTITY_TABLE feature flag enabled in your environment. Contact your Customer Success Manager to enable this feature.

Lifecycle Management Troubleshooting

How can I export or view the complete JSON configuration of a policy?

The Show Raw JSON optional feature allows you to view and export the complete JSON representation of a Lifecycle Management policy for debugging and troubleshooting purposes.

Accessing Raw JSON

To view the raw JSON configuration:

Go to Lifecycle Management > Policies
Select a policy to view its details
Click Show Raw JSON in the policy header actions (if enabled for your tenant)
The complete policy configuration displays in a modal window
Use the Copy JSON button to copy the configuration to your clipboard

What's Included

The raw JSON export includes the complete policy structure:

Policy metadata (name, description, state, version information)
Workflow configurations and trigger conditions
Action definitions and parameters
Transformer mappings and attribute configurations
Data source associations and identity mappings
Access profile assignments and permissions
Safety limit configurations
Notification templates and settings
Secondary identity source configurations

The raw JSON feature is useful for providing complete policy configurations when working with support teams, and understanding the underlying policy structure. Use this option for creating backups of complex policy configurations and debugging complex policy behaviors.

This feature may require enablement for your tenant. Contact your Customer Success Manager if the "Show Raw JSON" button does not appear in your policy header actions.

The raw JSON contains sensitive configuration information. Only share policy JSON with authorized personnel and avoid exposing credentials or other sensitive data when sharing configurations.

For more information, see Policy Settings in the Policies documentation.

What roles can access Lifecycle Management and Access Profiles?

Access to Lifecycle Management and Access Profiles is managed through Veza's role-based permission system. User permissions can vary based on their assigned roles and team membership, enabling separation of duties and security controls across the platform.

Only Administrator roles have full management capabilities for LCM policies and Access Profiles. All other roles provide various levels of read-only access, with some specialized roles offering additional functionality like integration management or review assignment.

Role Categories and Access Levels

Veza roles fall into two availability tiers that determine their LCM access capabilities. Generally Available roles can be assigned without additional configuration, while Early Access roles require enablement by Veza support before assignment.

Role

Availability

Team Support

LCM Policies & Workflows

Access Profiles

Special Capabilities

Administrator

Generally Available

Root only

Full access: Create, edit, delete policies and workflows

Full access: Create, edit, delete Access Profiles and types

System configuration, user management

Operator

Generally Available

Root, Non-root

Read-only access to policies and workflows

Read-only access to Access Profiles

Can create Access Reviews (Root team only)

Access Reviewer

Generally Available

Root only

Read-only access for assigned review purposes only

Limited to assigned review contexts

SCIM Provisioner

Generally Available

Root only

Read-only access to policies and workflows

Read-only access to Access Profiles

SCIM 2.0 user lifecycle management

Integrations Manager

Generally Available

Root, Non-root

Read-only access to policies and workflows

Read-only access to Access Profiles

Integration configuration and management

Integration Owner

Generally Available

Root, Non-root

Read-only access to understand integration impacts

Read-only access to profile assignments

Specific integration ownership and monitoring

Access Reviews Monitor

Generally Available

Root only

Limited read-only access for monitoring review activities

Limited read-only access for monitoring purposes

Access Review progress monitoring without modification

Viewer

Early Access

Root, Non-root

Read-only access for monitoring

Requires ROOT_TEAM_VIEWER feature for Root team access

Watcher

Early Access

Root only

Read-only access for monitoring (cannot make changes)

Read-only access for monitoring

View Review Configurations without modification capability

Auditor

Early Access

Root only

Read-only access for audit and compliance purposes

Read-only access for audit purposes

Export audit logs and compliance reporting

Re-assigner

Early Access

Root only

Read-only access with ability to re-assign review results

Read-only access with review result re-assignment

Can reassign Access Review results to different reviewers

OAA Push

Early Access

Root, Non-root

Read-only access for monitoring

Upload Open Authorization API (OAA) payloads

Programmatic Key Manager

Early Access

Root, Non-root

Read-only access for monitoring

Programmatic API key lifecycle management

OAA CSV Manager

Early Access

Root, Non-root

Limited access for CSV integration management

Limited access related to CSV integrations

Required for CSV Upload integration management

NHI Security Admin

Early Access

Root only

Read-only access with focus on non-human identity security features

Read-only access with NHI focus

Non-Human Identity security dashboards and risk assessments

Understanding Team-Based Access Control

Team assignments determine the scope of data and integrations that users can access within their assigned roles. The Root team provides unrestricted access to all integrated data providers, while custom teams limit access to specific team-assigned integrations.

Root Team Access grants users visibility into all LCM policies across every integrated provider, the ability to create Access Reviews and manage system-wide configuration, and access to administrative roles that require platform-wide permissions. This team is essential for users who need comprehensive oversight of lifecycle management operations.

Non-Root Team Access restricts users to viewing only LCM policies relevant to integrations within their team's scope. These users cannot create Access Reviews or access system-wide administrative features, but they can effectively manage policies and profiles within their designated integration boundaries. Non-root teams are recommended for departmental teams or application-specific access control scenarios.

Multi-Team Membership allows users to belong to multiple teams simultaneously, with potentially different roles in each team. Users can switch their "active team" context to access different sets of policies, profiles, and data based on each team's integration scope. This supports organizational structures where users need varied access levels across different systems.

Automated Role Assignment Through SSO

Organizations using Single Sign-On can streamline user management by automatically assigning Veza roles based on Identity Provider (IdP) group membership. This integration uses SAML/OIDC claims to map IdP groups to specific Veza team and role combinations using the format Team SSO Alias:role name (where Team SSO Alias and role name are placeholders—do not include curly braces).

For example, the following IdP group-to-role mappings are valid:

Root:admin → assigns the "admin" role in the "Root" team
Engineering Team:operator → assigns the "operator" role in the "Engineering Team"
Finance:viewer → assigns the "viewer" role in the "Finance" team

Single IdP groups can map to multiple team/role combinations, and administrators can configure default fallback assignments for users without specific group mappings.

This approach reduces manual user management overhead while ensuring consistent role assignments based on organizational structure. For SSO configuration guidance, see Role Mapping for Single Sign-On.

Implementation Considerations

When planning role assignments, consider that policy and Access Profile management requires Administrator privileges, which are restricted to Root team members. The Veza interface automatically adjusts to user permissions—non-administrator users won't see create, edit, or delete options for resources they cannot modify.

All permissions are enforced consistently across both the web interface and API endpoints, ensuring security regardless of access method. Organizations should carefully plan team structures and role assignments to balance operational efficiency with security requirements, particularly when implementing SSO-based automated role assignment.

For role descriptions, team management guidance, and SSO integration details, see User Roles and Permissions, Team Management, and User and Team Management APIs.

Why isn't my workflow triggering for certain users?

Several factors can prevent workflows from triggering. Here are some recommended diagnostic steps:

Attempt a Dry Run Simulation
- View details for the specific identity in question
- Review the messages field for workflow evaluation details
- Check which conditions passed/failed
Check for Common Issues
- Condition Mismatch: Identity attributes don't match workflow conditions
- Policy State: Policy might be in PAUSED or PENDING state
- Source Data: Identity might not exist in the configured data source
- Safety Limits: Changes blocked due to safety threshold
Validate Identity Attributes
- Verify the identity has the expected attribute values
- Ensure attribute mappings are configured correctly
- Check for data quality issues in the source system

Policy States

Policies can be in the following states:

INITIAL - Newly created, not yet running
RUNNING - Active and processing identities
DRY_RUN - Testing mode without making changes
PAUSED - Temporarily stopped
PENDING - Awaiting configuration or approval

The Dry Run messages will explicitly state why each workflow did or didn't match.

PreviousWorkday NextSeparation of Duties (SoD)

Last updated 6 days ago

Was this helpful?