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

In this section

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 .

4. Build Policies

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

Permanently removes user accounts from target systems. Unlike the DEPROVISION_IDENTITY action which disables or suspends accounts while preserving audit records, DELETE_IDENTITY performs complete account removal.

Example Use Cases:

• Database user cleanup after employee offboarding

• Compliance with data deletion policies (e.g., GDPR right to be forgotten)

• Removing test or temporary accounts

• Service account lifecycle management

• Contractor account removal after project completion

Supported Integrations:

• Active Directory (Users and Managed Service Accounts)

• Okta

• Google Cloud (Google Workspace Users)

• PostgreSQL

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

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

Dashboard Overview

The dashboard is organized into several key sections:

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

• Access Profiles: Shows configured and usage metrics

• Identities: Provides a visualization of managed identities

• Integrations: Top enabled for Lifecycle Management and Access Requests along with any error statuses

• Access Requests: Tracks pending and completed access requests

• Errors: Displays recent Lifecycle Management and Access Requests errors requiring attention (past day, week, or month)

• Recent Activity: Shows the most recent Lifecycle Management and Access Requests

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.

From the dashboard, you can perform common tasks including:

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

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

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

• Monitor system health: Review the Errors section for any issues

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 .

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 .

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.

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.

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.

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.

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.

After familiarizing yourself with the dashboard:

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.

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.

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:

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 . When a workflow runs and conditions match, Veza queues and creates an access review campaign based on the configured certification plan.

Use LCM-triggered access reviews to:

• Automatically certify access when employees change roles (movers)

• Review permissions before offboarding (leavers)

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

Dynamic Approvers is an Access Requests feature that lets Veza automatically determine who should approve an access request based on runtime context, access profile metadata, and external data.

Instead of assigning static approvers in a policy, you will configure a transformer pipeline that processes request attributes, access profile properties, and lookup tables to compute approver email addresses when the request is submitted.

Use Dynamic Approvers when approval routing will depend on metadata that can vary per request. For example, this can enable workflows in which Access Profiles assigned a specific cost center are routed to the appropriate approver group, or to assign managers based on department code.

How it works

When an access request is submitted, Veza evaluates any policy steps configured with a Dynamic Approver:

1. Veza considers the name of the Access Profile or Catalog Definition being requested, and any custom properties set on that profile.

2. Each transformer step in the Dynamic Approver pipeline runs in sequence, processing the available attributes to produce an intermediate or final output.

3. The final transformer step must output one or more approver email addresses.

4. Veza assigns those email addresses as approvers for that policy step.

The following attributes are available as inputs to transformer expressions:

Custom property attributes (access_profile_properties.* and catalog_definition_properties.*) are populated from the custom attribute definitions configured in . The attribute names available in the transformer editor reflect the definitions currently configured in your tenant.

Transformer expressions use the same syntax as Lifecycle Management : {attribute} for a direct reference, or {attribute | FUNCTION, arguments} to apply a function.

The most common function for Dynamic Approvers is LOOKUP, which resolves a value by looking it up in a . Lookup tables are CSV-based reference tables that map values between systems — for example, mapping department codes to approver email addresses. They are uploaded and managed within Lifecycle Management policy configurations.

The LOOKUP syntax is: {value | LOOKUP, "table_name", "match_column", "return_column"}

For example:

This takes the department custom property value from the Access Profile, looks it up in the dept_approvers lookup table by matching the dept_code column, and returns the corresponding approver_email value. See for details on creating and managing lookup tables.

You can chain multiple transformer steps. Use {last_output} in a subsequent step to reference the output of the previous step.

1. Go to Lifecycle Management > Settings.

2. Select the Access Request Settings tab.

3. Scroll to the Dynamic Approvers section and click Create Approver.

4. Enter a Name and optional

This example resolves a department code to approver usernames via a lookup table, then appends a domain to produce email addresses.

Step 1 — Look up approver usernames from department code

Output Type: String List

Step 2 — Convert usernames to email addresses

Output Type: String

Before linking a Dynamic Approver to a policy, use the built-in test configuration to verify it resolves to the expected approver emails.

1. In the Create or Edit Dynamic Approver dialog, scroll to Test Configuration.

2. Under Test Source, select Access Profile or Catalog Definition, then choose a specific record to test with.

3. Optionally, add Policy Properties — key-value pairs that simulate additional request context during testing.

If the test returns no results or an unexpected value, check that the referenced lookup table is populated, the custom property values are set on the selected profile, and the attribute names match your definitions.

Once a Dynamic Approver is configured, link it to an approval step in an Access Request Policy:

1. Go to Lifecycle Management > Settings > Access Request Policies.

2. Create or edit a policy.

3. Under Approver Settings, add or edit an approval step.

4. Set the step category to Dynamic.

When an access request matches this policy, Veza runs the selected Dynamic Approver pipeline at request time to determine the approver(s) for that step.

Queries the Veza Access Graph for entities during workflow execution. This is a read-only lookup that does not create or modify entities. Retrieved nodes are available to subsequent actions and conditions in the workflow.

Example Use Cases:

• Verify a user exists and is active in a target system before submitting a provisioning request (e.g., check that an OktaUser is active before assigning an application)

• Look up entity attributes from the graph to use in downstream transformer expressions

• Check if a role or group exists before attempting to assign it

The SCIM filter supports dynamic template variables (e.g., {attribute_name}) that resolve at runtime using values from previous actions. See for details on template syntax.

Rather than re-running an identical query on every execution, Get Node From Graph can reuse a result Veza already computed. A stored result is reused only while it is less than five minutes old, measured from the time that result completed. Past five minutes the action runs a new query, so workflows act on values from the most recent extraction instead of a day-old snapshot.

This five-minute bound is specific to Lifecycle Management graph reads. Other callers of the same query service use its default of 24 hours, which is what this action used before the bound was introduced.

Two related behaviors affect what a workflow sees:

• When a matching query is still running, the action uses that query's result rather than starting another, regardless of when the query began.

• Lifecycle Management keeps a separate ten-minute cache for the single-node lookups used by other actions, such as relationship management. The five-minute bound applies to this action's queries and does not shorten that cache.

The staleness window is not configurable.

This example shows a workflow that checks if a user exists and is active in Okta before submitting a provisioning request:

1. Trigger condition: employment_status eq "ACTIVE" — fires for new hires or active employees

2. Get Node From Graph action: Query for OktaUser with filter email eq {email} — looks up the user by their email address in the Okta integration

3. ENTITY_TYPE_IN_OUTPUT condition: Check if the previous action returned any OktaUser

Each retrieved node is an entity from the Access Graph with the following data:

Retrieved nodes are added to the workflow context and can be used in three ways:

Use to check whether the action returned any nodes of a given type, or to check the graph directly. These conditions control which subsequent actions execute.

Subsequent Get Node From Graph or actions can reference retrieved node attributes in their SCIM filters and payloads using transformer template variables. The transformer service resolves {EntityType.attribute} expressions against the accumulated nodes.

For example, if a Get Node From Graph action retrieved an OktaUser node with login = "jsmith@company.com", a subsequent action's filter could reference {OktaUser.login} to use that value.

Note: The entity type prefix is case-sensitive and must match the graph type exactly (e.g., OktaUser, not oktauser). Attribute names are case-insensitive.

Multiple Get Node From Graph actions can run in sequence. Each action's results accumulate in the workflow context, so later actions and conditions can reference nodes from any earlier action. This enables multi-step lookups — for example, first look up a user, then look up their manager.

Resets user passwords in target systems. Configuration options and behavior vary by integration.

Example Use Cases:

• Reset passwords for new users who must change on first login

• Enforce password rotation policies

• Recover from account lockouts

Creates email accounts for identities through integrated email providers. This action is typically used in onboarding workflows alongside and to provision a user account, create their email, and update the HR system with the new address.

Example Use Cases:

• Create Exchange Server mailboxes for new employees during onboarding

• Provision Azure AD email accounts as part of identity lifecycle workflows

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

Key features

• Automated Provisioning and De-provisioning: Streamline granting and revoking entitlements as employees join, move within, or leave the organization

• Environment-wide Synchronization: Keep user attributes and access rights consistent across applications and platforms

• Customizable Workflows: Design tailored processes for different lifecycle events and user segments

• Compliance and Audit Support: Maintain detailed records of access changes to support compliance and audit efforts

• Integration with Identity Providers: Integrate with identity providers and HR systems, import HR data from CSV, or use a custom OAA template

Reference documentation:

• - Conceptual guide to the different evaluation systems

• - SCIM filter syntax for workflow conditions

• - Complete list of transformation functions

• - Formatter-based profile assignment

Policies define the rules and actions for managing identities throughout their lifecycle. They specify what actions should occur when there are changes in a source of identity, such as when a user is created or their attributes change.

After configuring a policy for a source of identity in your organization, Veza Lifecycle Management tracks the source for changes. When employee records are added or changed, actions will trigger based on the workflows and actions specified in the policy. Learn more about .

Workflows are sequences of actions within a policy that execute based on specific conditions. They enable automation of lifecycle management processes such as onboarding, role changes, and offboarding.

Workflows only execute actions on users that meet specific conditions, and Policies can contain more than one Workflow. This enables you to create a single policy for your source of identity that contains multiple workflows, with one applying to new hires, another applying to terminated employees, and so on for the different JML scenarios you want to automate. Learn more about .

Access Profiles define sets of entitlements (such as group memberships or role assignments within a target application) that should be granted to users based on their role within the organization (or another distinguishing attribute). You can use Access Profiles to define both Business Roles – segments of employees, and Profiles – collections of entitlements in a target application.

Assigning Business Roles to the Profiles they should inherit enables you to define the birthright entitlements for different types of employees in your organization. You can then assign those Business Roles when configuring workflows that add or remove access to an application. Learn more about .

Lifecycle Management Actions are tasks performed within a workflow, such as creating a user account, assigning group memberships, or disabling an account. Actions can be combined to trigger in sequence when there are changes in the source of identity. Actions can run for any identity that meets the workflow conditions, or only apply when action-level conditions are met. Learn more about available .

Transformers allow you to modify and format user attributes when synchronizing data between systems, ensuring consistency and compatibility when creating users across applications.

Lifecycle Management will provision new users with these attributes and can keep their accounts up-to-date when there are changes in the source of identity. Target entity attributes can be set to specific values or use metadata from the source of identity, and support a range of transformation functions. Learn about .

Lifecycle Management uses several systems that evaluate identity attributes, each serving a distinct purpose:

• Workflow Conditions: SCIM filter expressions that determine whether workflows and actions execute (e.g., is_active eq true). Output is boolean.

• Attribute Transformers: Formatter expressions that determine what value an attribute should have (e.g., {first_name | UPPER}). Output is a string.

• Dynamic Access Profiles: Formatter expressions that resolve to Access Profile names at runtime (e.g., dept-{department | LOWER}

These systems can work together. For example, workflow conditions can embed transformer syntax for dynamic date comparisons. For a guide to when and how to use each, see .

Customize email notifications sent during Lifecycle Management events and Access Request workflows. You can personalize messaging, add branding, and include event-specific information through placeholders. Learn more about .

1. Enable Integrations: Configure your data sources and enable them for Lifecycle Management.

2. Define Access Profiles: Create profiles that map your organizational structure to application-specific entitlements.

3. Create Policies: Add policies to automate identity management processes.

For an overview of Lifecycle Management configuration using Okta, Workday, and Active Directory, see .

For API documentation, see .

Triggers email notifications and webhooks based on lifecycle events and action success or failure. Notifications can be added to any action type under Edit Action > Action Notification Settings.

Example Use Cases:

• Alert IT staff when provisioning is complete

• Notify managers of access changes

• Create a service desk ticket for any manual steps

• Send standardized notifications using custom templates across workflows

When configuring email notifications (either as a Send Notification action or in Action Notification Settings), you can choose which template to use:

• Default template: Uses the built-in event-specific template based on the lifecycle event being processed

• Custom template: Uses a reusable custom email template you've created, allowing consistent messaging across multiple workflows

Custom templates support the same placeholders as event-specific templates, enabling dynamic content like identity names, workflow names, and action results. See for placeholder reference and template management.

Rotates cryptographic keys in Azure Key Vault by creating a new key version. The action targets one or more named keys in a specified vault and runs rotations concurrently (up to five keys in parallel). Each key's result is reported individually, so partial success is possible.

Example Use Cases:

• Rotate Azure Key Vault keys on a scheduled basis to meet compliance requirements

• Automatically rotate keys when a service account is offboarded

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.

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

Attribute synchronization ensures that identity attributes in target systems remain up to date with the corresponding attributes in the source of truth. Veza Lifecycle Management provides configuration at two levels to control how and when attributes are synchronized.

At the action level, there are two distinct options to govern provisioning and user update processes:

• Create new users - When enabled, the action will create new user accounts that don't exist in the target system

• Update active users - When enabled, the action can update existing user accounts with attribute changes from the source of truth

Introduces a deliberate delay in the workflow execution.

Example Use Cases:

• Allow time for system propagation between actions

• Implement rate limiting in multi-step workflows

• Coordinate timing with external processes

Disables or suspends user accounts in target systems when employees or contractors leave the organization. Unlike Delete Identity, which permanently removes accounts, Deprovision Identity preserves the account and its audit history while revoking access — allowing for potential reactivation if needed.

Example Use Cases:

• Disable Active Directory accounts and move leavers to a terminated users OU

• Suspend Okta accounts while preserving group membership history for audit

• Revoke access and reassign resources when employees transition out of the organization

• Lock accounts during investigations while maintaining forensic records

The exact deprovisioning behavior depends on the target application and the method configured in the action. Integrations may support one or more of the following:

Not all integrations support all methods. The available methods are determined by the integration's DeProvisionIdentityDefinition and are shown in the action configuration dropdown.

See the in the Actions overview for a complete Active Directory offboarding configuration.

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

• 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

• - How source attributes map to Veza

• - Computed attributes for advanced logic

When connecting to integrated systems (see ), Veza ingests properties from the source systems (e.g., Workday, Okta, Active Directory) and normalizes them into standardized attributes that appear when configuring Workflow trigger conditions, configuring Actions, and in views.

While these standardized attributes are intended to ensure consistent naming across different systems, it is important to understand that some attributes may appear differently than their original names in the source system.

You can retrieve the original attribute names for enabled Lifecycle Management integrations using the API.

Veza normalizes all property names for consistency:

Executes integration-specific operations that extend beyond standard Lifecycle Management action types. CUSTOM_ACTION enables integrations to define specialized operations with flexible attribute schemas tailored to their unique capabilities.

Example Use Cases:

• Insert records into ServiceNow tables when employees join or change roles

• Create ServiceNow incidents or requests as part of onboarding workflows

Overview

REST Auth Credentials provide centralized, reusable authentication configurations for Send REST Payload actions in Lifecycle Management workflows. Instead of configuring authentication directly in each action, you can create named credential sets that multiple actions can reference.

Benefits:

• Reuse: Share authentication across multiple Send REST Payload actions

• Security: Sensitive fields (passwords, tokens, secrets) are encrypted at rest

• Centralized management: Update credentials in one place; all referencing actions use the latest configuration

• Audit: Track credential usage and creation history

1. Navigate to Lifecycle Management > Settings

2. Select the Rest Credentials tab

3. Click Create to add a new credential

4. Enter a Name for the credential

REST Auth Credentials are managed via the Lifecycle Management API:

Create a credential:

List credentials:

Get a single credential:

Update a credential:

Delete a credential:

Provides a custom authorization header value. Use this for API keys or non-standard token formats.

The value is sent as the Authorization header on each request.

HTTP Basic authentication with username and password.

Veza constructs the Authorization: Basic {base64(username:password)} header automatically.

Bearer token authentication.

Veza constructs the Authorization: Bearer {token} header automatically.

Two-step authentication: perform a login request, then extract a bearer token from the response. Use this for APIs that require an initial authentication step before issuing a session token.

How it works:

1. Veza sends a POST request to login_url with login_payload_json as the body

2. The JSON response is parsed using bearer_token_attribute to extract the token

3. The extracted token is used as a Bearer token for the actual REST request

Example:

If the login API returns:

Set bearer_token_attribute to value.token to extract the token.

OAuth 2.0 client credentials flow.

Veza performs the client credentials flow to obtain an access token, then uses it as a Bearer token for the REST request.

Choosing an authentication method:

• FORM (default): Sends client_id and client_secret as form-encoded parameters in the POST body alongside grant_type=client_credentials. Use this when the token endpoint expects credentials in the request body.

• BASIC: Sends credentials in the Authorization: Basic base64(client_id:client_secret) header, with only grant_type=client_credentials

Check your target API's OAuth2 documentation to determine which method it supports. Both conform to . When in doubt, try FORM first as it is the default and more widely supported.

No authentication header is added to the request. Use this when the target API is public or when authentication is handled through other means (e.g., network-level security, pre-shared keys in URL parameters).

When configuring a action in a Lifecycle Management policy:

1. In the action configuration, select a credential from the REST Auth Credentials dropdown

2. The credential provides the authentication header and optional default URL/method

3. The action's Webhook URL and HTTP Method settings override the credential defaults when specified

• : Action configuration and payload options

• : Route requests through Insight Points for on-premises targets

• : Attribute transformation syntax for dynamic URLs and payloads

Creates entitlements (groups, roles, or distribution lists) in target systems as part of lifecycle workflows. This action supports creating new entitlements, renaming existing ones, and synchronizing entitlement membership.

Example Use Cases:

• Dynamically create department-specific Active Directory security groups during onboarding

• Provision Okta groups for new teams or projects as part of organizational changes

• Create Azure AD distribution groups for new departments

• Create AWS IAM Identity Center groups for team-based access management

• Automatically add newly created entitlements to Access Profiles for downstream provisioning

When an existing entitlement ID is provided, the action renames the entitlement rather than creating a new one. This is useful when organizational changes require updating group or role names while preserving existing membership and access.

When Sync Members is enabled, the action compares the current entitlement membership against the expected member list and:

• Adds members that should be present but are missing

• Removes members that are present but should not be

• Tracks individual member operations, reporting successes and failures separately

This enables precise entitlement membership management as part of lifecycle automation.

Newly created entitlements can be automatically added to an . This enables workflows where creating an entitlement in one step makes it available for assignment in subsequent Manage Relationships actions, connecting dynamic entitlement creation with birthright access provisioning.

CREATE_ENTITLEMENT generates three notification event types:

You can configure email notifications or webhooks for these events. See for configuration details.

The Provisioning Activity page 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.

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

1. Policies define the overall automation framework for managing identities

2. Workflows determine which actions should be executed for specific identities

Updates an HRIS or identity source with an email address created earlier in the same workflow. This ensures the source of identity (such as Workday) contains the employee's new corporate email address, and keeps records consistent across systems.

The address comes from an upstream action, usually . This action has one setting, Entity Type: you choose where the address is written, not what gets written. It writes the address the upstream action produced without modifying it, so you cannot select among several addresses or reformat one. To set the identity source's email to a value you choose, use instead.

Example Use Cases:

• After creating an Exchange Server mailbox during onboarding, write the new email address back to the Workday Worker record

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.

• You have the Administrator role on the root team

Makes HTTP requests to external APIs and services as part of provisioning workflows. This action enables integration with custom applications, webhooks, and REST-based services that support identity management operations.

Example Use Cases:

• Notify external systems when users are created or updated in target systems

• Trigger custom provisioning workflows in third-party applications

• Send identity data to SCIM endpoints for user synchronization

• Create service desk tickets for manual provisioning steps

• Execute webhooks to coordinate multi-system workflows

• Extract response data (like user IDs) from external systems for use in downstream actions

When constructing the webhook URL and JSON payload, you can reference identity attributes using curly brace syntax. Two sources of attributes are available specifically for this URL and payload context:

• Source-of-identity (SOI) attributes: Attributes from the identity source triggering the workflow (e.g., Workday worker fields, Okta user attributes).

• Sync Identities output entity attributes: When a Sync Identities action precedes this action in the same workflow, attributes from the provisioned or updated target user (such as Active Directory user attributes) are also available. See below.

• Generated password (Early Access): When a or action precedes this action and password output is enabled, the generated password is available as {EntityType.password}. See below.

Available transformations include UPPER, LOWER, TRIM, and accessing nested attributes with dot notation, such as {Manager.email}. See for complete transformation syntax.

Note: If any placeholder in the URL or payload cannot be resolved (e.g., due to missing attributes), the entire transformation is skipped and the original URL is used without any substitution. The system logs a warning for troubleshooting. Ensure all referenced attributes exist in the source of identity to enable proper variable substitution.

When a Send REST Payload action is configured as part of an Access Request , the JSON payload can reference form field values submitted by the requester. This enables dynamic payloads where the requester provides values (such as a role name or resource ID) at request time, and those values are injected into the API call.

Use the {$form_field.field_name} syntax in the JSON payload, where field_name matches a field defined in the catalog definition's form fields.

To configure form field substitution:

1. Create a Send REST Payload action in a provisioning policy with placeholders in the JSON payload:

2. Create a Send REST Payload and add form fields with names that match the placeholders (e.g., role_name, role_id).

3. When a user submits an access request using this catalog definition, they complete the form fields. The submitted values replace the corresponding {$form_field.*} placeholders in the payload before the REST call is made.

Form field substitution applies to the JSON payload only. It does not apply to the webhook URL or authorization header. Each placeholder must sit inside a JSON string literal (between two " characters), as in "roleName": "{$form_field.role_name}". Placeholders outside string context are left untouched so the resulting JSON fails to parse at execution time rather than silently emitting malformed JSON.

Substituted form-field values are JSON-encoded automatically. Quotes, backslashes, and control characters in the submitted value are escaped, so a value such as alice"bob is emitted as alice\"bob and cannot break out of the surrounding string literal.

Field names must contain only letters, numbers, and underscores (role_name is valid, role-name is not). A field whose name contains an unsupported character might be accepted at catalog-definition save time but is not substituted at execution time, and the literal {$form_field.*} placeholder is emitted in the payload. If a placeholder references a field that was not provided on the access request, the placeholder is likewise left unchanged.

The following attributes are populated on the sync_identities output entity for Active Directory integrations and can be used in variable substitutions:

Custom properties defined in the integration configuration are also available, using the key customprop_<property_name> (where <property_name> is the property's format name as configured).

When a or action precedes this action and password output is enabled, the password it generated is available to the webhook URL and JSON payload as {EntityType.password} — for example, {ActiveDirectoryUser.password}. This supports joiner workflows where Veza provisions an account and forwards the generated credentials to a downstream system such as an HR portal or ticketing API.

When "Add Response to Output Entities" is enabled, the action parses JSON responses and extracts specified entity data. This enables chaining actions where one API call creates a resource and returns an identifier that subsequent actions can reference.

For example, if a user creation API returns:

Configure the action with:

• Response Entity Attribute: result

• Response ID Attribute: user_id

• Response Name Attribute: display_name

The extracted entity becomes available to downstream workflow actions.

• GET: Query operations, typically without payload; use for checking resource state or retrieving data. Does not set workflow change flags

• POST: Create new resources; requires JSON payload; sets both AnyCreated and AnyChanges flags that can trigger downstream actions with "Only Send if Any Upstream Changes" enabled

• PUT: Replace entire resources; requires JSON payload; sets AnyChanges

Workflow Integration: The AnyCreated and AnyChanges flags enable conditional workflow execution. Actions configured with "Only Send if Any Upstream Changes" will only execute when a previous action has set these flags, allowing you to build sophisticated conditional workflows (e.g., only send a notification webhook if a user was actually created, not just updated).

The authorization header supports common authentication methods:

• No Authentication: Leave the authorization header empty when connecting to endpoints that don't require credentials, such as internal services or pre-authenticated URLs

• Bearer Token: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

• API Key: X-API-Key: secret-key-123 or Authorization: ApiKey sk-prod-xyz

• Only JSON payloads are supported (no XML, form-data, or other formats)

• Authentication must be header-based (OAuth flows requiring user interaction are not supported)

• Response parsing requires valid JSON if "Add Response to Output Entities" is enabled

• Timeout applies to entire request; no automatic retry on failure

Overview

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

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

Problem scenarios for attribute overrides

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

• Incorrect or slow-to-update attributes:

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

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

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

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

• Emergency access control:

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

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

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

• You have administrative access to Veza Lifecycle Management

• You understand which source identity attributes need to be overridden

• You have identified the specific identities requiring attribute overrides

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

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

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

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

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

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

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

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

2. Locate the identity requiring an attribute override.

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

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

   2.3 Click Details to open the expanded details view

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

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

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

To change the value of an attribute override:

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

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

3. Edit the override value.

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

   3.2. Select Edit Override from the dropdown menu

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

To remove an override:

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

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

3. Clear the override.

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

   3.2. Select Clear Override from the dropdown menu

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

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

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

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

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

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

Consider the following best practices when implementing attribute overrides:

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

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

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

Automatically creates access review campaigns during lifecycle events. This action bridges Lifecycle Management with Veza Access Reviews, enabling automated certification workflows triggered by identity lifecycle changes.

Example Use Cases:

• Review contractor access 30 days after onboarding to ensure appropriate permissions

• Certify elevated permissions after role changes or promotions

• Trigger periodic access reviews based on employment anniversaries

• Automatically review access for high-risk roles or sensitive systems

• Create access reviews when users join specific departments or teams

The Certification Creation Plan is the core configuration element for CREATE_ACCESS_REVIEW:

The Review Name field accepts attribute transformers, so the name a review receives depends on the identity that triggered the workflow. Test the formatter from the action editor before saving the policy.

1. In the Review Name section of the Create Access Review action, select Test.

2. In Test Review Name Formatter, enter a sample value for each attribute the formatter references. Veza detects the attributes in the formatter and displays one input for each. Timestamp attributes accept ISO 8601 or RFC 3339 values, such as 2026-01-31 or 2026-01-31T09:15:32Z.

3. Select Test Formatter.

The generated name appears under Formatter Output. When the formatter produces more than one candidate value, the first four appear with an option to display the rest. If the formatter cannot be evaluated, the error replaces the output and Save stays disabled until you correct the formatter.

Selecting Save in the modal writes the edited formatter back to the action.

Veza evaluates the formatter on the server against the policy's current version, so results reflect the transformers and lookup tables that version defines. Conditional (IF) formatting is not available on this field.

1. A lifecycle event triggers a workflow containing the CREATE_ACCESS_REVIEW action

2. The action evaluates the Certification Creation Plan against the identity that triggered the event

3. A review campaign is queued in Veza Access Reviews

4. The review campaign is created and assigned to the designated reviewers

CREATE_ACCESS_REVIEW generates two notification events:

You can configure email notifications or webhooks for both events to track review creation progress. See for configuration details.

Related Topics:

• : Behavior, filtering, entity matching, and troubleshooting

• : Configuring certification plans and managing reviews

• : Managing birthright entitlements included in reviews

Without automated lifecycle management, organizations face a fragmented identity and access management landscape. Multiple systems require manual coordination, leading to delays in provisioning, security gaps from orphaned accounts, and compliance risks.

Veza Lifecycle Management provides a unified platform that automates identity provisioning and de-provisioning across your entire technology stack. Changes in your HR system automatically trigger coordinated workflows across all connected applications, ensuring consistent access management throughout the employee lifecycle.

Before you begin creating draft for automating Lifecycle Management workflows, you should establish and document how employees in your organization are mapped to business roles, and corresponding birthright entitlements (default access permissions granted based on an employee's role) such as groups and roles in target applications.

Implementing Veza Lifecycle Management will require:

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.

System attributes use two prefix conventions: sys_attr__ for computed boolean flags evaluated each extraction cycle (such as sys_attr__is_mover) and sys_attr_changed__ for per-property change detection attributes that are also re-evaluated each cycle. Neither can be manually set or modified.

A boolean attribute that indicates whether an identity has undergone changes to monitored properties during the most recent extraction.

Type: Boolean Persistence: Transient (re-evaluated each extraction cycle) Available in: Workflow trigger conditions