Start here to understand Lifecycle Management fundamentals, monitor your LCM environment, and track workflow execution.

In this section

Where to go next

After reviewing the getting started materials:

1. Configure Integrations: Enable your identity sources and target applications for LCM. See .

2. Set Up Identities: View and manage identities from your configured sources. See .

3. Create Access Profiles: Define birthright entitlements for user segments. See .

For an end-to-end walkthrough using Workday, Okta, and Active Directory, see .

Policies define the rules and actions for managing identities throughout their lifecycle. Workflows within policies execute based on specific conditions, automating processes such as onboarding, role changes, and offboarding.

In this section

Key concepts

• Policies: Top-level configuration for a source of identity that defines which workflows apply

• Workflows: Sequences of actions that execute when specific conditions are met

• Trigger Conditions: Boolean expressions using SCIM filter syntax (e.g., is_active eq true)

Related topics

• - Define birthright entitlements for provisioning actions

• - Format attributes when provisioning accounts

Identities are the core entities in Lifecycle Management. They represent the people in your organization, sourced from HR systems, identity providers, ITSM platforms, payroll systems, custom OAA applications, or flat files. See Integrations for the full list of supported identity sources.

In this section

Key concepts

• Source of Identity: The authoritative system (such as Workday or Okta) that provides identity data

• Identity Attributes: Properties like first name, last name, email, department, and manager

• Override Attributes: Custom attributes that can supplement or override source-provided values

Related topics

• - How source attributes map to Veza

• - Computed attributes for advanced logic

Overview

System attributes are computed properties that Lifecycle Management automatically generates during identity processing. These attributes enable advanced automation scenarios by providing runtime information about identity changes and transformation results.

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

Veza's Lifecycle Management (LCM) solution empowers organizations to automate and streamline the management of user identities and access rights throughout the employee lifecycle. From onboarding to role changes and offboarding, automated LCM workflows ensure that the right people have the correct access at the right time.

Key features

• Automated Provisioning and De-provisioning

The Lifecycle Management Dashboard provides a centralized interface for monitoring automatic provisioning and deprovisioning of user access - both birthright access granted by Veza Lifecycle Management and just-in-time access granted by Veza Access Reviews. This dashboard gives you an at-a-glance view of your configuration, status, and recent activity.

The dashboard is the primary landing page for Lifecycle Management and Access Requests and can help with routine monitoring, error resolution, policy validation, activity review, and integration health checks.

Dashboard Overview

The dashboard is organized into several key sections:

• Policies: Displays your most recently updated Lifecycle Management and their status

• Access Profiles: Shows configured and usage metrics

• Identities: Provides a visualization of managed identities

To navigate to more detailed information, click on any section heading to open the related overview. Click on specific items (such as a policy or integration) to view or edit configuration details.

Dashboard Actions

From the dashboard, you can perform common tasks including:

• Create a new policy: Click the "Create Policy" button in the Policies section

• Configure Access Profiles: Click the "Create Access Profile" button in the Access Profiles section

• Set up a new integration: Click the "Set up Integration" button in the Integrations section

Policies

The Policies section displays all configured Lifecycle Management policies with their current status. Each policy shows its name, associated identity source, number of identities managed, and current status (Running/Stopped).

You can view all policies at a glance, create new ones with the "Create Policy" button, see which policies are actively running, access detailed configuration by clicking on a specific policy, and verify that policies in "Running" status should be active. Learn more about .

Access Profiles

The Access Profiles section shows the total number of configured access profiles and provides a visual representation of profile activity. Access profiles define sets of entitlements granted to users based on their roles.

You can see the total number of configured profiles, create new ones using the "Create Access Profile" button, view profile activity and utilization, and access detailed configuration by clicking into the section. Learn more about .

Identities

The Identities section provides a visual representation of all identities managed through Lifecycle Management and Access Requests. The chart displays the distribution of identities by type or status, giving you an immediate understanding of your identity landscape.

This visualization helps you understand the overall composition of your managed identities, identify distribution patterns across different categories, and track changes in identity distribution over time.

Integrations

The Integrations section lists all systems connected to Lifecycle Management and Access Requests, displaying the total number of integrations, error status and counts, recently created integrations, and last update timestamps. For each integration, you can see its name and type, current status (including error indicators), and last update timestamp. You can set up new integrations using the "Set up Integration" button, identify and troubleshoot integration errors, and view all integrations by clicking "View all." Review this section regularly to identify any integrations with error states. See for more information.

Access Requests

The Access Requests section tracks pending access requests, recently completed requests, and request status (Pending, Completed, Rejected, Cancelled). This section provides visibility into the access request process, allowing you to monitor request volume and status, track completion rates, and identify potential bottlenecks in the access request workflow.

Errors

The Errors section displays any Lifecycle Management and Access Requests errors that require attention. When functioning normally with no issues, this section will display "No issues found." If errors occur, this section will list the specific errors, provide context about when and where they occurred, and offer guidance on troubleshooting and resolution. Check this section regularly for any reported issues.

Recent Activity

The Recent Activity section shows a chronological log of Lifecycle Management and Access Requests events, including event type, timestamp, affected identity, and entity name. Examine this section to identify any unusual patterns or failed operations. This activity log helps you track recent actions, verify that expected changes have occurred, identify patterns or issues in lifecycle events, and monitor the overall health of your Lifecycle Management or Access Requests implementation.

Next Steps

After familiarizing yourself with the dashboard:

Overview

This guide explains how to disable individual workflows or actions within a Lifecycle Management policy. Disabling allows you to temporarily pause specific parts of a policy without deleting or modifying the underlying configuration.

Use this option when developing workflows to support:

• Managing gradual rollouts: Enable actions one at a time to verify each step before activating the next

• Troubleshooting issues: Isolate problematic actions without removing configuration

• Implementing seasonal policies: Temporarily disable workflows that only apply during certain periods

• Workflow Testing: Disable production actions while testing new workflow logic

Disable a workflow

Disabling a workflow prevents it from running during policy execution. All conditions and actions within the workflow are also skipped.

1. Go to Lifecycle Management > Policies.

2. Select a policy and click Edit Workflow.

3. Toggle the workflow's Enabled control to disabled.

The policy editor displays disabled workflows and actions with a "Disabled" tag.

Disable an action

You can also disable specific actions within a workflow without disabling the entire workflow. When you disable an action, any nested conditions and actions under the disabled action are also skipped, but other actions in the workflow continue to run normally.

1. Open the workflow editor.

2. Select the action you want to disable.

3. Toggle the Enabled control in the action settings.

Test disabled workflows with dry run

Disabled workflows are evaluated by default during dry run simulations. This allows you to preview what would happen if you re-enabled a disabled workflow and validate trigger conditions and action configurations before making them active.

When you run a dry run simulation, the results show what actions would run if the workflow were enabled.

Re-enable a workflow or action

To re-enable a disabled workflow or action, toggle the Enabled control back to enabled and save.

See also

These guides provide step-by-step instructions for common Lifecycle Management tasks and configurations.

In this section

Additional resources

• - Common questions and troubleshooting

• - Architecture overview

• - Monitor workflow execution and policy status

Overview

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

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

Overview

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

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

Access Profiles govern how application entitlements are assigned to employees across your organization. These profiles define how birthright access should be granted based on segmentation criteria, such as business role, job function, seniority level, location, or group membership. Access Profiles are used by the Manage Relationship action to assign users to specific groups, roles, permission sets, or other access-granting entities when specific conditions are met.

Profiles can be configured hierarchically to create a fine-grained model for assigning access to different employee groups. Administrators can position child profiles beneath a parent profile, with each child profile inheriting the parent profile's entitlements.

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

Example Profiles

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

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

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

• Any entitlements inherited from a parent Profile.

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

Access Profile Types

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

Profiles

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

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

Business Roles

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

Best Practices for Access Profile Types

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

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

Configuring Access Profiles

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

1. Click Create Access Profile.

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

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

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

When configuring a policy to include the Manage Relationships action, you can select any active profile for the target data source. You can also use Dynamic Access Profiles to resolve Access Profile names at runtime based on user attributes. See for details.

Access Profile Ownership

Access Profiles can have designated owners who are responsible for managing and maintaining the profile. Owners have elevated permissions to configure the profile, manage its lifecycle, and create additional profiles.

Who Can Be Owners

Both Veza Users and Veza Groups can be assigned as Access Profile owners:

• Individual Users: Any Veza platform user with the appropriate permissions

• Veza Groups: Both Customer Managed groups (created in Veza) and SCIM Managed groups (provisioned from identity providers). See for details on group types and management

Owner Eligibility Requirements

To be eligible as an Access Profile owner, a user or group must have the Creator permission set for the relevant Access Profile Type. This is a two-step configuration process:

1. Grant Profile Type Permissions:

   • Navigate to Lifecycle Management > Settings

   • Select the Profile Types tab

Owner Permissions

When a user or group is designated as an Access Profile owner, they automatically receive three distinct permissions:

1. Owner permission on the specific Access Profile

   • Read: View the profile's configuration, entitlements, and metadata

   • Update: Modify the profile's settings, labels, descriptions, and assigned relationships

These permissions enable owners to not only manage their assigned profiles but also create additional profiles of any type they have access to.

Managing Owners

Access Profile owners are managed through the Access Profiles interface:

1. Navigate to Lifecycle Management > Access Profiles.

2. Locate the Access Profile in the list.

3. Click the Actions button (⋮) for that profile.

See Also

Overview

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

Understanding Fallback Formatters

When provisioning new identities through Lifecycle Management, unique attributes like usernames, login IDs, or email addresses must not conflict with existing values. Fallback formatters provide an automated way to generate alternative values when conflicts arise, ensuring provisioning can proceed without manual intervention.

You can configure fallback formatters when configuring a to ensure new users can be onboarded efficiently, regardless of naming conflicts.

Use Case: Username Conflicts

The most common use case for fallback formatters is handling username conflicts. For example:

Your organization uses a standard username format of first initial + last name (e.g., jsmith for John Smith).

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

• John Smith already has jsmith

• Jane Smith already has jsmith1

• James Smith already has jsmith2

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

Configuring Fallback Formatters

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

1. Edit or create a Lifecycle Management policy

2. Edit the workflow containing the Sync Identities action

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

Transformer Options for Fallback Formatters

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

Using the NEXT_NUMBER Transformer

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

The NEXT_NUMBER transformer:

• Generates a set of sequential integers as strings

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

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

Other Useful Transformers for Fallbacks

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

Using Random Alphanumeric for Unique Usernames:

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

Using UUID for Guaranteed Uniqueness:

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

Implementation Example

When configuring a fallback formatter with the NEXT_NUMBER transformer:

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

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

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

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

Common Fallback Patterns

Here are some commonly used fallback patterns:

How Fallback Resolution Works

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

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

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

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

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

This guide explains how to create Access Reviews from Lifecycle Management workflows and troubleshoot common issues.

Lifecycle Management (LCM) policies can trigger Access Reviews automatically using the CREATE_ACCESS_REVIEW action. When a workflow runs and conditions match, Veza queues and creates an access review campaign based on the configured certification plan.

Overview

Use LCM-triggered access reviews to:

• Automatically certify access when employees change roles (movers)

• Review permissions before offboarding (leavers)

• Validate access grants after onboarding (joiners)

• Enforce periodic re-certification based on identity attribute changes

The sections below cover configuration options and troubleshooting for reviews created by LCM workflows.

Troubleshoot missing reviews

Common scenarios:

• All results filtered: Veza created the review but then deleted it because all rows already appeared in recent in-progress reviews

• Entity type mismatch: The policy identity type does not match the access review query, and no identity graph relationship exists to resolve it. Veza displays this error: "No matching node type found for identity type {type}"

• Missing workflow configuration: The Access Review workflow is not configured or not linked to the policy

LCM-triggered reviews always run when a workflow executes, but Veza deletes the review if it has no results after filtering.

Veza compares each row against the last five in-progress reviews (by default) for the same workflow. The system excludes rows that appeared in any of those reviews. If all rows are excluded, Veza deletes the review rather than completing it with zero results. Veza does not send notifications for deleted reviews.

To verify a review was created and deleted:

• Check Veza Events for the review creation and deletion

• Review Lifecycle Management event logs for the workflow execution

• Note: Deleted LCM-triggered reviews do not appear in the Reviews list (unlike manually-created empty reviews, which do appear)

Understand unchanged result filtering

LCM and Rule-triggered Access Reviews automatically exclude unchanged results. Veza enables this setting by default, and you cannot disable it for these review types.

When Veza creates a review, it compares each row against the last five in-progress reviews for the same workflow (sorted by start time, newest first). The system excludes rows that appeared in any of those reviews, leaving only new or changed access to review.

This behavior:

• Applies automatically to all LCM_TRIGGERED and RULE_TRIGGERED reviews

• Compares against the last five in-progress reviews by default (configurable by Veza support)

• Cannot be changed through the UI or API

If filtering excludes all rows, Veza deletes the review rather than completing it with zero results. Veza does not send notifications for deleted reviews, but the deletion appears in Veza Events.

Resolve entity type mismatches

LCM-triggered access reviews require the policy identity entity type to match the entity type defined in the access review query. Veza resolves this match in the following order:

1. Direct match in source node types: The policy identity type matches directly

2. Direct match in destination node types: The policy identity type matches the destination

3. Linked nodes through the identity graph: Veza follows graph relationships to find a connection (for example, WorkdayWorker → ActiveDirectoryUser

If none of these resolve, the review creation fails with the error: "No matching node type found for identity type {type}".

Example: If your policy tracks WorkdayWorker identities and your review expects ActiveDirectoryUser entities, Veza still creates the review successfully if there is a defined relationship (for example, WorkdayWorker → ActiveDirectoryUser) in the identity graph. If no such mapping exists, the review creation fails.

Fix missing enriched identity columns

Access Reviews can include enriched columns that display additional identity attributes (such as department or manager from an HRIS system). However, Veza skips enrichment when the identity mapping is ambiguous.

When Veza skips enrichment:

If a single account or entity maps to multiple identity nodes in the graph (for example, one Active Directory account maps to two different WorkdayWorker records), Veza intentionally skips enrichment rather than arbitrarily choosing one.

Result:

• Veza still creates the review successfully

• Enriched columns appear but remain empty for affected rows

• Veza logs a trace-level warning: "Skipping enriching nodes due to finding multiple linked nodes"

Resolution:

Review your identity mappings to ensure each account maps to a single identity. Ambiguous mappings often indicate data quality issues in source systems (such as duplicate employee records).

Customize review names

When creating access reviews through LCM workflows, you can configure a custom review name using attribute transformers. This is useful when a workflow creates multiple reviews and you need to differentiate them.

Common use case (Movers): When employees change roles, a single workflow run can trigger multiple access reviews. Custom names help reviewers identify which review corresponds to which change.

Transformer syntax:

Use curly braces to reference identity attributes:

• Review for {name} → "Review for John Smith"

• {department} Access Review - {name} → "Engineering Access Review - John Smith"

• {job_title} Certification → "Senior Engineer Certification"

See for the complete transformer syntax reference.

Dry Run verification:

Custom review names appear in Dry Run results, allowing you to verify the name format before the workflow runs in production. This helps catch transformer syntax errors or missing attributes early.

Related topics

• : Complete guide to configuring and managing access certification campaigns

• : Creating and configuring certification plans

• : Configuring the workflow action settings

Overview

By default, only Administrators can create Access Profiles in Lifecycle Management. With Access Controls enabled, Administrators can grant Creator permissions to specific Operators and Groups, allowing them to create new profiles. Users who create a profile automatically become its Owner and can edit that profile, but cannot modify profiles created by others. Administrators always retain full access to all profiles.

Users must have the Operator role to use Creator permissions — non-Operator roles (Access Reviewer, Watcher, etc.) cannot create Access Profiles even with explicit permission grants.

Before you start

• You have the Administrator role on the root team

• Access Controls are enabled on your tenant (contact Veza support)

• The users receiving permissions have the Operator role assigned

Grant Access Profile creation permissions

To assign Access Profile creation permissions to users or groups:

1. Navigate to Lifecycle Management in the Veza main navigation menu.

2. Click Settings in the Lifecycle Management sidebar.

3. On the Settings page, locate the Access Profile Types section.

Result: Users and groups with Creator permissions can now create new Access Profiles from the Lifecycle Management > Access Profiles page.

Verify permissions

To confirm that permissions were assigned correctly:

1. In the Manage Permissions modal, review the list of assigned users and groups.

   Each row shows:

   • Principal name (user or group)

   • Principal type (User or Group)

Remove Access Profile creation permissions

To revoke Access Profile creation permissions:

1. Navigate to Lifecycle Management > Settings.

2. Click Manage Access Profile Creation Permissions.

3. In the permissions table, locate the user or group to remove.

Result: The user or group can no longer create new Access Profiles. They retain read-only access to view existing profiles.

See also

• - Overview of the permission sets system

• - Understanding Access Profiles and their role in Lifecycle Management

• - Veza role definitions and capabilities

The Lifecycle Management Activity Log provides visibility into all provisioning operations performed by Veza's Lifecycle Management system. It serves as a record of all activities, including successful actions, errors, and failures.

Overview

A Lifecycle Management policy defines automated workflows that execute when changes occur in a source of identity. The Activity Log tracks all aspects of these operations through a hierarchical structure:

Overview

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

• Whether the profile can inherit entitlements from other profiles

Overview

This guide explains how to use dry run simulations to test Lifecycle Management policies before enabling them in production. Dry run evaluates workflow logic and shows what actions would occur without making actual changes to target systems.

Use dry run testing to:

Lifecycle Management automates identity provisioning across your applications. When an employee joins, changes roles, or leaves, workflows answer two questions: Should this person get access? And what should their account look like?

This document explains the building blocks: conditions that control when things happen, and transformers that control what values are set.

Terminology

These terms are used throughout Lifecycle Management documentation.

Quick Reference

The Four Systems

Workflow Trigger Conditions

Purpose: Determine whether a workflow should execute based on identity attributes.

Syntax: SCIM filter expressions that evaluate to true or false.

Example:

When to use: Gate workflow execution based on identity state, department, location, employment type, or other attributes.

See for complete syntax documentation.

Conditions on Success

Purpose: After a workflow trigger matches, determine whether subsequent actions should run.

Syntax: Same SCIM filter syntax as workflow triggers.

Example:

When to use: Create branching logic within a workflow where different actions apply to different identity subsets.

See for configuration details.

Attribute Transformers

Purpose: Construct attribute values when syncing identities to target systems.

Syntax: Formatter templates with optional pipeline functions.

Examples:

When to use: Transform source attributes into the format required by target systems (usernames, email addresses, distinguished names, etc.).

Transformers also support IF/ELSE conditional logic to select different values based on identity attributes. See for complete documentation.

Dynamic Access Profiles

Purpose: Dynamically determine which Access Profile to assign based on identity attributes.

Syntax: Formatter templates (same as attribute transformers) that resolve to Access Profile names.

Example:

If user's department is "Engineering", this resolves to the Access Profile named dept-engineering.

When to use: Assign Access Profiles based on department, location, role, or other attributes without creating separate workflow conditions for each combination.

See for complete documentation.

Combining Conditions and Transformers

Conditions and transformers can work together. Workflow trigger conditions can embed transformer syntax for dynamic value comparisons.

Example: Time-Windowed Leaver Trigger

This condition triggers a leaver workflow when an employee's last day falls within a 2-day window around today:

Breaking it down:

The syntax {\| FUNCTION \| ...} (pipe immediately after opening brace) indicates a transformer with no source attribute—it starts directly with a function like NOW.

See for more examples.

Summary

Related Topics

• - Complete SCIM syntax for workflow triggers

• - Formatter syntax and pipeline functions

• - All available transformation functions

Overview

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

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

Enabling Lifecycle Management for Snowflake

Prerequisites

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

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

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

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

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create a Snowflake integration

3. Check the box to Enable usage for Lifecycle Management

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

1. Go to Veza Administration > System Settings

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

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

To verify the health of the Lifecycle Management data source:

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

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

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

Supported Actions

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

The integration supports the following lifecycle management :

Sync Identities

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

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

• Login names are used for authentication and must be unique

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

The following attributes can be synchronized:

Manage Relationships

Role assignment management for users:

• Add and remove role assignments for users

• Synchronize role memberships from source systems

• Support for direct role grants to users

Within Snowflake, roles can be associated with:

• Database and schema access permissions

• Table and view privileges

• Warehouse usage rights

• Administrative privileges for account management

Deprovision Identity

When a user is deprovisioned:

• User account is disabled (set DISABLED = TRUE)

• Role assignments are removed to revoke access

• User attributes are preserved for audit purposes

Workflow Examples

Employee Onboarding

Automated provisioning when a new employee joins:

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

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

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

Role Change Management

Managing access when employees change roles:

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

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

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

Employee Offboarding

Secure access removal when employees leave:

1. Disable Account: Set user account to disabled status

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

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

Identities

Identities in Veza Lifecycle Management represent a top-level view of an individual user, used to automate provisioning and deprovisioning across systems, applications, or services.

This can include birthright access managed throughout the user's lifecycle, triggered by joiner, mover, or leaver events, as well as ad-hoc, just-in-time access granted upon approval of an access request.

Identities can refer to users who may be employees, contractors, or external collaborators (partners). Additionally, Veza supports lifecycle management for Non-Human Identities (NHI), such as service accounts, though with a simplified action set. See for details on NHI-specific capabilities and limitations.

With Lifecycle Management, workflows defined within policies dictate the users’ onboarding, job-function change, and offboarding processes, ensuring that corresponding identities have precisely the access they need as their roles evolve or their status within the organization changes. Similarly, access granted to identities may also change as just-in-time access requests are fulfilled or revoked.

The Lifecycle Management > Identities page serves as a central hub for viewing identities known to Lifecycle Management and Access Requests, as well as performing actions on individual identities.

Identities are populated into Lifecycle Management by first identifying the entire user population by integrating their source of identity (SOI) and creating a policy that uses that data source, into a Veza tenant. This may require enabling a built-in integration for your identity source (e.g., Workday integration), uploading user data in CSV format (CSV Upload integration), or using a custom OAA connector.

See for detailed information on integrating the source of identity.

For Integration management using APIs, see .

Identity Synchronization

Identities are maintained through synchronization with the identity sources. Syncing identities ensures that all systems reflect the most current user state, whether through onboarding, role changes, or attribute updates, keeping access aligned, consistent, and audit-ready.

The Sync Identities action is used for the automatic synchronization of user identities between an authoritative source (such as an HR system or identity provider) and target systems. In the Lifecycle Management workflow, Sync Identities works alongside other key actions:

• Manage Relationships (handling group/role memberships)

• Deprovision Identity (removing access when users leave the organization)

Synchronization is executed through Lifecycle Management policy workflows. Policy workflows can be defined with triggers and actions to synchronize changes in your identity source with target systems. Additionally, SCIM (System for Cross-domain Identity Management) or OAA (Open Authorization API) can enable identity sync for a wide range of target applications that don't have a built-in Veza integration, but do expose standard user and group management APIs or support bulk data export.

• See for more information on usage.

• See for detailed information.

Multi-Value Attribute Management

Active Directory supports appending values to multi-value attributes during Identity Sync actions. This allows you to add new values without replacing existing ones.

For detailed information about appending multi-value attributes, including supported attributes, syntax, and examples, see in the Transformers documentation.

Identities Table

Note: The display name is not the primary unique identifier, as multiple users may share the same first and surname.

Identity attribute display priority

When an identity has multiple sources (primary and secondary), the Identities table displays attributes 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 account in a secondary system).

Display Priority:

This behavior ensures the table reflects the most current and relevant source of identity information. For example, when an employee terminates (primary source becomes inactive) but remains as an active contractor in a secondary source, their attributes are displayed from the contractor system.

Filter and Search an Identity

To start, you can use filtering options to locate specific identities or analyze a group of identities based on standard criteria. The following filters are available on the Identities overview:

• Search by name: Locate specific individuals using a name-based search

• Department filter: View identities by organizational unit

• Status filter: Filter by Active or Inactive employment status

Identity Actions

For each identity record, administrators can perform actions through the Actions menu:

• View Details: Access identity information, attribute history, and related accounts

• Trigger Workflow: Manually initiate a workflow in a policy

• Request Access: Launch an Access Request for additional access (requires Veza Access Requests).

  See for customizing the Request Access Template.

View User Details

Click on your selected identity to open the Identity Details view.

The following fields in the Identity Details view are populated with the current user's information:

• Title: The user’s position title.

• Email: The user's email address.

• Providers: A list of assigned integrations. When you click a specific provider, the Integration page opens, displaying the provider's detailed information, including its Entity Categories distribution.

Attribute Overrides

When executing a policy where user attributes at the source of identity are incorrect, slow to update, or temporarily need adjustment, you can override the existing attribute with a different value until the issue is corrected. For more information, see .

Here are some examples of incorrect or slow-to-update attributes:

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

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

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

To create an Override Value, perform the following:

1. Select an identity by name.

2. Click Details.

3. Click Properties in the Details menu.

Performing Actions on an Identity

Click the overflow icon (three dots) to display options for performing actions on the identity. Next, click on the desired action:

• Trigger Workflow

• Request Access

• Show in Graph

Trigger Workflow

The Trigger Workflow option is a convenient way to test a specific user in a policy workflow. For example, you can test a new employee's identity in a joiner workflow to evaluate whether they have sufficient access to perform their duties.

Use the Trigger Workflow option to manually run a workflow for a specific user.

To trigger a workflow with a specific user, perform the following steps:

1. Select a workflow in the dropdown menu.

2. Click Trigger to run the workflow.

Request Access for an Identity

Requests Access allows for additional or temporary access grants, particularly when a user’s current access is insufficient for their duties.

Use the Request Access option in the Identity Details view to grant access to a specific user while reviewing their detailed information. You can grant access to the user through the following:

Access Profiles option

A collection of entitlements that are granted as part of the user’s identity lifecycle requirements. Access Profiles can:

• Define reusable collections of entitlements across multiple target systems by business roles, departments, or functions

• Automate consistent access provisioning

• Manage access profile types and their capabilities

See and for more information.

To grant an Access Profile, perform the following:

1. Click the Access Profile radio button.

2. The Choose from Access Profile window appears.

3. Enter a Reason for granting the Access Profile for the user.

App option

An App refers to a target system, where user access is provisioned or deprovisioned as part of the identity lifecycle process.

To grant an App, perform the following:

1. Click the Access Profile radio button.

2. The Request Grant Access window appears.

3. Enter a Reason for granting the App for the user.

Entitlements option

Granting Entitlements to a user provides specific access permissions (roles, permissions, group memberships) required to perform their responsibilities.

Note: By granting Entitlements to a specific user, you pre-fill an Access Request with the appropriate configuration settings and policy.

To grant an Entitlement, perform the following:

1. Click the Entitlements radio button.

2. The Request Grant Access window appears.

3. Enter a Reason for granting the Entitlement for the user.

Show in Graph

Use the Show in Graph option to display a graph that represents all assigned Access Profiles, Apps, and Entitlements, including all associations.

This is a graphical representation of John Smith’s assigned access and entitlements to roles/groups.

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

Supported Capabilities

Lifecycle Actions Supported

Create Email

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

• Entity Type: Exchange Server Users

• Attributes Available for Configuration:

  • Identity (Required)

Example Use Cases:

• Create email accounts for new employees joining the organization

• Assign email aliases to users to facilitate communication

Configuration Steps

1. Locate Exchange Management Shell Paths

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

2. Right-click > More > Open File Location
3. Right-click the shortcut icon > Properties

2. Create Application Pool in IIS

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

3. Configure IIS Application

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

   • Set alias to "VezaProvisioner"

4. Install Veza Provisioner

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

5. Configure Exchange Server Integration in Veza

1. Go to Configurations > Integrations

2. Click Add New and select Exchange Server

3. Complete the following fields:

   Field

6. Verify Configuration

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

Overview

The Veza integration for Google Cloud enables automated user provisioning, access management, and de-provisioning capabilities for Google Workspace. This integration allows you to synchronize identity information, manage group memberships, and automate the user lifecycle from onboarding to offboarding.

Overview

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