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 Workday, Okta, and Active Directory and Implementation and Core Concepts.

See also:

• Managing Identities

• Policies

• Attribute Transformers

• Integrations

Dry Run Testing

Can I test policy changes before making them live?

Yes, dry run simulations let you safely preview policy changes before deployment. Dry run evaluates workflow logic and shows what actions would occur without making actual changes to target systems. You can test a single identity or run bulk dry runs against multiple identities with filtering options.

For step-by-step instructions, see Test policies with dry run.

What does a dry run test?

Dry run evaluates the selected identity against all workflows in a policy and shows:

• Matched workflows: Which workflows triggered and why

• Planned actions: What provisioning or deprovisioning would occur, including full action configuration details

• Access profiles: Which access profiles would be assigned or removed

Dry run does not test integration connectivity or validate that actions would succeed. It only evaluates whether workflow conditions are met.

For step-by-step instructions, see Test policies with dry run.

Policy Configuration

What happens when an action fails in a workflow?

When an action fails, the entire workflow retries on the next policy run—not just the failed action. All actions (including previously successful ones) re-execute unless configured with "Skip if action has already been run".

Retry configuration (API only):

Property	Description	Default
no_retry_for_failed_workflow	Disables automatic retry when set to true	false
max_retries_for_failed_workflow	Maximum number of retry attempts	10

Example: If Azure Sync fails after AD notifications, the workflow retries and notifications send again. Enable "Skip if action has already been run" on notification actions to prevent duplicates.

What is the "Skip if action has already been run" option?

This safety mechanism prevents the same action from executing multiple times for the same identity, even if the workflow re-triggers. LCM tracks successful completions per identity and skips the action if already completed.

Enable for one-time actions:

• Create Email, Welcome notifications, Initial Password Setup, One-time provisioning

Disable for repeatable actions:

• Sync Identity, Manage Relationships, Deprovision Identity

Key behaviors:

• Only successful completions mark an action as "run"—failed actions continue to retry

• Condition-based skips don't affect state (action runs when conditions become true)

• Clear action history via API to force re-execution

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:

1. Create Policy: Go to Lifecycle Management > Policies > Create Policy

2. Configure Source: Select your HR system or IDP as the data source

3. Add Workflows: Define triggers for Joiner, Mover, and Leaver scenarios

4. Configure Actions: Set up provisioning, deprovisioning, and access assignments

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

How do I temporarily disable workflows or actions?

You can pause or disable specific workflows and actions within a policy for safer testing and gradual rollouts, without deleting or modifying the underlying configuration. Disabled workflows and actions are skipped during policy execution, and the policy editor displays them with a "Disabled" tag.

Disabled workflows are still evaluated during Dry Run simulations by default, so you can test workflow logic before enabling it in production.

For step-by-step instructions, see Disable workflows and actions.

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, rather than syncing only once at creation time.

Why use Continuous Sync:

• Keeps downstream systems current - Attribute changes (title, manager, department) propagate automatically

• Reduces drift - Avoids stale or inconsistent values that impact compliance

• Supports policy logic - Updated attributes can trigger dynamic policy conditions

Configuration overview:

Continuous Sync requires configuration at multiple levels:

1. Action level: Enable "Update active users" on Sync Identity actions

2. Attribute level: Select "Set for new and existing users" for attributes that should stay synchronized

For complete configuration details, recommended settings, and best practices, see Attribute Synchronization.

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 (groups, roles, or permissions) that can be automatically assigned to users based on their attributes. They serve two key functions:

• Birthright Access: Automatically assigned through policy workflows during joiner/mover/leaver events via the Manage Relationships action

• Just-in-Time (JIT) Access: Available for request through Access Requests, with provisioning managed by LCM policy

Access Profile Types (Business Role, Entitlement, Application, etc.) determine behavior and can be configured hierarchically for fine-grained access control.

For complete documentation including configuration, profile types, ownership, 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.

Parallel Execution and Paused Tasks

When parallel workflow processing is enabled, paused tasks (waiting for approval, delays, etc.) free up running slots, allowing other tasks to start. This can create scenarios where many paused tasks bypass the safety limit check when they resume.

To mitigate this, configure the max_paused_slots setting to limit how many paused tasks can free up running slots:

• First N paused tasks: Free up slots (allowing new tasks to start)

• Additional paused tasks: Remain counted as "running" (preventing new tasks from starting)

This setting is configured via the parallel execution settings API (see Parallel Execution Settings below).

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

How do I configure parallel execution settings?

Lifecycle Management supports parallel workflow processing, allowing multiple workflows to run concurrently. Configure parallel execution using the private API endpoint at /api/private/lifecycle_management/parallel_execution_settings.

Key settings include:

• jobs: Maximum concurrent policy jobs

• workflows: Maximum concurrent workflows per job

• access_requests: Maximum concurrent access request workflows

• max_paused_slots: Limits how many paused tasks can free up running slots (prevents safety limit bypass)

For complete API reference, configuration examples, and detailed explanation of max_paused_slots behavior, see Parallel Execution Settings API.

Notifications

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

Lifecycle Management supports notifications at two levels with different capabilities:

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
Best for	User and stakeholder communications	Simple operational confirmations

Choosing the right level:

• Use policy-level for user-facing notifications requiring entity context (usernames, emails, relationship details). These support dynamic recipients and rich placeholders like {{ENTITY_NAME}} and {{LOGIN_NAME}}.

• Use action-level for operational monitoring where you only need confirmation that an action completed, without entity-specific details.

The {{LOGIN_PASSWORD}} placeholder is only available for CHANGE_PASSWORD and RESET_PASSWORD events, not for identity creation events.

For configuration details, see:

• Policy Notifications - Event-based notifications with entity context

• Send Notification Action - Action-level notification configuration

• Notification Templates - Placeholders and custom templates

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:

1. New Data Push - A new CSV file is uploaded or an OAA payload is pushed

2. Policy Configuration Changes - Any policy update forces a re-extraction

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

What happens when an extraction takes longer than the scheduled interval?

Veza has built-in guardrails to prevent overlapping extraction jobs for the same data source. A new extraction job is enqueued only if there is no pending or in-progress job for that data source.

Job Scheduling Behavior

When an extraction is scheduled to run every hour but takes longer than one hour to complete:

1. If an extraction job is already running, scheduled extractions during that time are skipped

2. The next extraction runs at the first scheduled time after the previous job completes

3. Skipped scheduled runs are dropped—they don't queue up for later execution

For example, supposing an hourly extraction schedule, where an extraction starts at 2:00 AM but takes 4 hours and 30 minutes to complete:

• 2:00 AM - Extraction job starts

• 3:00 AM - Scheduled extraction skipped (job still running)

• 4:00 AM - Scheduled extraction skipped (job still running)

• 5:00 AM - Scheduled extraction skipped (job still running)

• 6:00 AM - Scheduled extraction skipped (job still running)

• 6:30 AM - Initial extraction completes

• 7:00 AM - Next scheduled extraction runs successfully

In this scenario, the scheduled jobs at 3:00 AM, 4:00 AM, 5:00 AM, and 6:00 AM are dropped because an extraction was already in progress.

This behavior applies to all extraction schedules and is not specific to any particular integration or API. It is intended to prevent system resource exhaustion from simultaneous extractions.

Note that each data source is evaluated independently, and extractions for different data sources can run concurrently. Manual extraction triggers will also be skipped if an extraction is already running for that data source

If you notice that extractions are consistently taking longer than your scheduled interval, consider adjusting the schedule frequency to accommodate typical extraction durations. Monitor extraction times in the integration activity logs to determine optimal scheduling.

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

1. Combine Multiple Columns: Create full names from first/last name columns

2. Extract Data: Gather domains from email address values

3. Format Dates: Convert date formats to match target system requirements

4. Apply Business Logic: Set department codes based on location values

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

1. The CSV is immediately converted to OAA (Open Authorization API) format

2. Only the OAA payload is stored, not the original CSV

3. Any re-extraction uses this stored OAA payload

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

What SCIM attributes does Veza support?

Veza supports SCIM 2.0 attributes for both read-only data extraction and Lifecycle Management synchronization. The specific attributes available depend on whether you're extracting data for the Access Graph or synchronizing user/group information through LCM.

Core User Attributes

For LCM Synchronization, Veza supports the standard SCIM user attributes including:

• Identity & Authentication: userName (required), id, externalId, active

• Contact Information: emails, phoneNumbers, addresses, ims

• Personal Information: displayName, givenName, familyName, middleName, nickName

• Professional Information: title, userType, locale, timezone, preferredLanguage

For Read-Only Extraction, all SCIM core attributes are captured, including additional metadata such as profileUrl, photos, createdAt, and lastModified.

Group Attributes

Veza supports standard SCIM group attributes including displayName, id, externalId, groupType, description, and members for both extraction and LCM operations.

Extension Attributes

Enterprise Extension Support: Veza can synchronize Enterprise Extension attributes including department, division, employeeNumber, costCenter, organization, and manager for both read-only extraction and LCM.

Custom Extensions: Veza automatically discovers and extracts all custom vendor-specific SCIM extension attributes for read-only purposes (they appear in the Access Graph). You can synchronize Custom vendor extensions when Extension Schema Discovery is enabled, by referencing the normalized attribute name when constructing a transformer for Lifecycle Management or Access Requests.

For the complete attribute reference with data types, requirements, and LCM capabilities, see the SCIM Lifecycle Management integration 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

1. LCM creates an email account in the target system (e.g., Exchange, Azure)

2. The newly created email address is written back to the user's record in the SOI

3. 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	Early Access - contact Veza support to enable
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 in Early Access but are now standard functionality available to all tenants.

How does Veza determine the active state and other attributes when an identity has both primary and secondary sources?

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

Default behavior:

• Always displays the primary source attributes if a primary source exists

• Only displays secondary source attributes if no primary source exists

Enhanced behavior (Early Access):

Primary Source Status	Secondary Source Status	Displayed Attributes Source
Active	Any	Primary source
Inactive	Active	Secondary source
Active	Active	Primary source (default)
Inactive	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 enhanced behavior enabled, the Identities table displays attributes from the contractor system, reflecting their current active status.

Early Access: Enhanced identity source prioritization may require Veza support to enable. Contact your Customer Success Manager for availability.

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:

1. Go to Lifecycle Management > Policies

2. Select a policy to view its details

3. Click Show Raw JSON in the policy header actions (if enabled for your tenant)

4. The complete policy configuration displays in a modal window

5. 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	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	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	Read-only access for monitoring	Upload Open Authorization API (OAA) payloads
Programmatic Key Manager	Early Access	Root, Non-root	Read-only access for monitoring	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:

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

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

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