Policies
Configure automated workflows for Lifecycle Management actions, including common attribute transformers and event notification settings
Overview
Lifecycle Management policies define the workflows that are triggered when a user is added or other events are detected at a specific source of identity. Workflows contained in a policy describe conditional sequences of actions that can be structured based on the specific joiner, mover, leaver (JML) scenarios that you want to automate. This might include hiring a new employee, terminating an existing employee, transferring an existing employee to another department, or other actions triggered by changes in status.
A policy can contain one or more workflows that run under different conditions. For example, one workflow might be applied when employees enter an "Active" state (for Joiner/Rehire scenarios), and another when an employee becomes "Inactive" (for Leaver scenarios). A workflow could also be triggered when an employee's hire date falls within a certain threshold, such as being less than 4 days away, or when it is related to any other employee property within the source of identity.
For most enterprise deployments, Veza recommends:
One policy for each source of identity integrated with Lifecycle Management
Two workflows within each policy:
One for active users to cover Joiner and/or Mover scenarios (including Re-hire)
Another for inactive users to cover Leaver scenarios
Add a Lifecycle Management Policy
To create a policy for a source of identity:
Go to Policies.
Click Create Policy.
Enter a policy name and description.
The policy name is used to identify it on the Policies list and event logs
The name should indicate the source of identity that the policy applies to
Select a Primary Identity Source using the arrows to display a list of available data source integrations.
The selected identity source will trigger workflows in the policy
For the identity source to appear in the menu list, the integration must have Lifecycle Management enabled and be available as a source of identity (SOI).
See Integrations for a list of supported providers and the steps to enable a Lifecycle Management data source.
Note: A Lifecycle Management data source can only be used to trigger workflows in one policy at a time. However, you can assign multiple Lifecycle Management data sources to a single policy as Primary Identity Sources. For example, Company A merges with Company B using Active Directory as its Primary Identity Source. The Primary Identity Source can be comprised of two integrations: Company A AD (from a CSV Upload integration) and Company B Employee Directory (from an OAA integration).
(Optional) Use the Additional Identity Source to add more data sources and correlating attributes.
Click Add Source.
Use the arrows to search for an Identity Source.
In Primary Attributes, select a primary attribute from the dropdown menu.
In Additional Attributes, select another attribute from the dropdown menu.
Click Add to add more Primary Attributes and/or Additional Attributes.
The Only enrich identity if existing in Primary Identity Source option controls identity creation:
Enabled: Only adds data to existing identities from the Primary Identity Source. Does not create new LCM identities.
Disabled: Creates new LCM identities when users exist in the Additional Identity Source but not in the Primary Identity Source.
Click Save. The policy is automatically set to the Initial state.
Simulation Dry Run on Policy
The Dry Run allows you to simulate and preview how a Policy would process an identity, without making actual changes to target systems. This testing tool helps you validate workflow conditions, preview potential changes, and understand what actions would be triggered for specific identities.
How Dry Run Works
The Dry Run evaluates workflow logic but does not interact with target integrations. Verify integration health to ensure target systems are accessible before running actual policies. Dry Run takes a policy and an identity to simulate:
The workflows triggered
All actions that would run
What Access Profiles would be assigned
Any potential changes to entities and attributes
You can test how policies would respond to identity attribute changes for different scenarios during a Dry Run simulation without impacting the actual identity attribute values.
Starting a Dry Run
You can initiate a Dry Run in two ways:
From a Lifecycle Management Policy
When editing a policy, open the Dry Run tool to preview changes for any identity:
Go to Policies.
Click a policy to view its details.
Click Dry Run Policy at the top right.
Choose the identity and policy to test workflows.
Select one or more attributes to sync. You can modify attributes to simulate potential changes.
Click Show Results.
Review the results:
Check the Workflows Run section to see which workflows were triggered.
Check the Potential Changes section to see all job requests that would be generated (e.g., edits to user attributes, adding/removing access profiles).
From Identity Details
You can start a Dry Run when viewing details for any account on the Identities page:
Go to Identities.
Search for an identity and click to view its details.
Expand the Actions menu at the top right and click Policy Dry Run.
Select a policy, customize entity attributes, and click Show Results.
Dry Run Notes:
Result: 0 Changes
When a dry run returns "0 changes", it means:
The selected identity does not meet any of the trigger conditions defined in your policy's workflows
No actions would be executed for this identity when the policy runs
This is not an error - it simply means the identity doesn't qualify for any of the configured workflows
Limitations
Dry Run has several important limitations:
Dry Run evaluates whether workflow conditions are met, not whether actions would succeed
It does not check whether integrations are functioning properly and whether target systems are accessible
It does not validate that changes could be successfully applied
A broken integration might cause workflow-defined changes not to be applied to an identity
Best Practices
Use Dry Run to validate that policies and their workflows are working as intended before enabling them in a live environment.
Test with Representative Identities: Select identities that represent different scenarios (new hires, role changes, terminations) to validate all workflows in your policy.
Simulate Different Scenarios: Modify identity attributes during Dry Run to test trigger conditions such as:
Department changes
Employment status updates
Location transfers
Role modifications
Test Edge Cases: Use Dry Run to test unusual scenarios or edge cases that might not occur frequently in your environment.
A Dry Run executes the workflow logic end-to-end, making no external changes. It evaluates conditions, decides which actions would run, and logs the decisions and payloads. That makes it ideal for probing unusual or risky situations without touching real accounts or entitlements. Here are some edge case examples:
Handling long names or names with special characters
Department and location change at once
Same-day rehire after termination
Policy Version
Policies can be version-controlled, allowing for a method to refine and test changes in your automation workflows. You can create draft versions to test changes and validate updates before deployment while maintaining a history of previous configurations. Each policy can have only one active version and one draft version at a time, with automatic archival of retired versions.
Policy State vs Workflow Versioning State
Policies have a current state that is based on their workflow operations.
The Policy state includes:
Initial - Initially created before the first workflow version is published
Running - Actively processing with one or more workflows
Paused - Temporarily disabled
Pending - Waiting for activation
Dry Run - In test mode
Note: In the Policies page, click on the Action overflow icon (three dots) to Start the policy in the Initial state, and Pause or Unpause at the Running state.
The Workflow Version state includes:
Draft - In draft mode for editing and modification
Published - Functional and active
Retired - No longer active or usable
Policy Draft Mode
The Policy Draft Mode is a state where a policy is saved but not yet active. In Policy Draft Mode, you can create, edit, and test policy configurations (such as workflows, actions, or mappings) without affecting real users, identities, or access profiles. Once you are satisfied, you can publish the policy, which moves it from the work-in-progress state to an operational state.
To enable the Policy Draft Mode, perform the following:
On the Lifecycle Management Dashboard page, click Settings in the top menu.
The Lifecycle Management Settings page appears. Click Policy Settings.
Switch ON the Enable Policy Draft Mode button.
Test Policy Workflows using Draft Versioning
You can test and refine your policy workflows to ensure that it is working as expected through a series of draft versions with Dry Run simulations. Once the workflow’s result is satisfactory, publishing the version will change the policy status to ‘active’.
Perform the following steps to test your policy workflow:
Create and save a new policy.
Create a new workflow and Save.
After creating a new workflow, click Publish.
By publishing your workflow, it is ready for activation by going to the Actions menu (three dots icon) and clicking Start. The Create Draft button is enabled.
Click the overflow menu (three dots) and select Perform Dry Run to test your workflow.
If you are not satisfied with the results of the Dry Run simulation, then click Create Draft. Your workflow will be labeled with a new version number.
Click Edit Workflow to make changes to your workflow.
Continue to modify your workflow using the previous steps until your workflow displays the expected results. Click Publish.
You can view the history of your workflow versions and rollback any draft version for use.
Published Policy
A published policy is activated and deployed with the following characteristics:
Enforces the defined rules in your environments, including:
Creating, modifying, or removing user access.
Synchronizing identity attributes.
Triggering workflows or notifications.
Becomes visible in reporting, monitoring, and compliance views.
It can still be updated by moving it back into Policy Draft Mode first.
Enabling and Monitoring Lifecycle Management Policies
Use the Policies page for an overview of initial, running, and paused policies. New policies are created in the "Initial" state, enabling a review period before activating the policy. Active ("Running") policies will apply the next time the data source is extracted.
To manage policies on the main Policies overview:
Go to Lifecycle Management > Policies
Find the policy you want to manage
Search for a specific policy by name
Filter to show all providers by their current state
Click the three dots icon ⋮ in the rightmost column to expand the Actions menu
View Details - Displays the date (or timeframe) the policy was last updated and its integrations. Use this view to create a workflow, transformer, property, password complexity rules, or transformer functions.
Pause - Pause the Running state of the policy.
Delete - Deletes the policy.
Add Workflows to Policies
Policies contain one or more workflows. Typically, workflows correspond to Active and Inactive user states, but not always. More specifically, workflows define a sequence of actions to run when a condition is met, based on events and identity changes captured at the source of identity. These workflows apply to scenarios such as new employee hiring, internal employee mobility changes (e.g., promotions, transfers, new managers), or employee departures.
Workflows comprise a tree-like sequence of conditions designed to meet the specific requirements of your joiner, mover, and leaver processes. For example, you may want to grant specific entitlements to users with specific roles, locations, or groups.
Workflows and Trigger Conditions
Trigger Conditions refer to rules or filters that initiate (or delay) provisioning and deprovisioning workflows based on certain events, criteria within identity data sources, or lifecycle workflows.
They are often tied to HR events, such as employee hiring (joiner), role changes (mover), or termination (leaver). For instance, provisioning flows can be triggered when an employee is hired or deprovisioned when terminated.
Trigger Conditions can be time-based, such as “create the Active Directory account 15 days prior to a new employee’s start date”.
Advanced implementations also support relationship-based triggers (e.g., launching workflows when a worker is added to a specific department). Note: Trigger conditions can also encompass transformer functions embedded in SCIM filter conditions, which enable more complex or refined triggering logic within workflows (e.g., matching specific attribute filters to drive provisioning).
Create a Workflow
To add a workflow, perform the following:
Select a policy.
Click Create Workflow.
In Details, enter the workflow name and description.
In the Priority field, use the dropdown menu to select:
Not set
Low
Normal
Medium
High
Critical
The levels dictate the order/priority in which the workflows are run. The higher-priority setting will be processed first. A fairness algorithm is built in to prevent lower-priority workflow tasks from being starved.
In the New Workflow pane, click the trigger attribute. The Edit Workflow pane appears.
Enable Continuous Sync to set controls change detection:
When enabled, the workflow monitors for any changes in the source of identity
When disabled, the workflow only runs during initial provisioning
See Attribute Sync and Transformers for more information on Continuous Sync.
In the Trigger Condition field, select a conditional string from the dropdown menu to create a logical syntax that automatically starts the workflow. Once a condition has been set, another conditional string can follow, or an action can be taken.
In the Trigger Details field, select the Attribute to Get the Execute Date from the dropdown menu to specify when the workflow actions should run.
In the Date Formatters, click Add Date Formatter.
Click the Formatter field to display a dropdown menu of operator functions, the Conditional Express function, and attributes.
Click the Pipeline Functions field to display a dropdown menu of operator functions. The Pipeline Functions combine a series of attribute formatters with the pipe (|) character, which runs the value of an attribute in sequential order. The output of one formatter becomes the input of the following formatter.
In the Local Time Zone Diff From UTC field, use the arrows to set your UTC offset:
Eastern Standard Time (EST): -5
Pacific Standard Time (PST): -8
Note: US UTC offset varies during Daylight Saving Time
In the Trigger At Local Time Hour field, use the arrows to set execution time in 1-hour intervals (e.g., 6, 12, 24)
In the Delay before triggering actions field, set the delay timeframe based on hours, minutes, and seconds.
Click Save Workflow. Note: All errors in the workflow must be resolved before it can be saved.
Clone or Delete a Workflow
Once an LCM Policy workflow is saved, the clone and delete options appear alongside the workflow name:
Click on the copy icon to clone the workflow.
Click on the trash bin icon to delete the workflow.
Create a Transformer
A transformer is a rule or function that takes incoming identity or attribute data and modifies it into the format or value that the target system requires.
They’re used when the data source system and target system represent or store information differently. For example, transformers can:
Converting a username from “First.Last” format into all lowercase.
Mapping a department value like “HR” in the source to “Human_Resources” in the target.
Adding a prefix or suffix to attributes (e.g., appending a domain name to create an email).
Transformers act as data processors inside a policy, ensuring that the right values are sent when provisioning, updating, or deprovisioning identities and entitlements.
To add a transformer, perform the following:
Select a policy.
Click Transformers.
Click Add Transformer.
In the New Transformer window, enter a transformer name and description.
Click the Integration field to display a dropdown menu of integrations of a target system.
Click the Entity Type field to display target entity types based on the integration that was previously selected.
In Attributes, click Add Attribute.
In Unique Identifier, click the Destination Attribute field to display a list of attributes.
Click the Formatter field to display a dropdown menu of operator functions, the Conditional Express function, and attributes.
Click the Pipeline Functions field to display a dropdown menu of operator functions. The Pipeline Functions combine a series of attribute formatters with the pipe (|) character, which runs the value of an attribute in sequential order. The output of one formatter becomes the input of the following formatter.
Optionally, click Add Attribute to add more attributes and repeat the attribute steps.
The Fallback Formatters option appears. Click this option to provide an alternative formatter when a conflict occurs if the primary formatter generates a value that is already in use.
Optionally, enable the Continuous Sync function to keep the target entity up-to-date with values from the source of truth.
Click Save.
See Transformer Reference for available transformation functions.
Create a Lookup Table
Lookup tables are CSV files with columns that map values from a source of identity to destination values. Each row represents a mapping entry. The first row must contain the column headers.
This example is a location mapping table, which is a typical format for a Lookup Table:
location_code,state_code,state,city
MN001,MN,Minnesota,Minneapolis
CA001,CA,California,Los Angeles
TX001,TX,Texas,Houston
TX002,TX,Texas,AustinOnce a Lookup Table has been uploaded, it can be processed with the Lookup Transformers. The Lookup transformers convert identity attributes from a source system into appropriate values for target systems based on CSV reference tables. This is particularly useful when mapping values between systems that use different naming conventions, codes, or formats for the same conceptual data.
Use Lookup Table Transformers to:
Map source attribute values to different values in target systems
Standardized reference data that must be consistent across applications
Extract different pieces of information from a single attribute value
Have complex mapping requirements that built-in transformers cannot support
See Lookup Table Transformers for detailed information.
To add a Lookup Table, perform the following:
Select a policy.
Click Lookup Table.
Click Add Lookup Table.
In the New Lookup Table window, enter a name and description for the Lookup table.
Drag and drop a CSV file or navigate to a CSV file to upload. The CSV file must be 10MB or less.
After uploading the file, you can preview it.
Click Save.
Create Properties
Properties are the attributes that describe identities, accounts, and entitlements. They serve as the data points a policy can use to determine when and how to take action. Properties can come from:
Built-in properties – default attributes that LCM provides out-of-the-box (for example: username, email, status, created_at).
Custom properties – attributes defined by your organization to capture unique metadata (for example: cost_center, employee_type, manager_id).
Use Properties to:
Properties are referenced in policy conditions (e.g., disable account if status = inactive).
Help with transformers and lookup tables, allowing you to map or reformat values.
Used in identity overrides when syncing accounts from different providers.
To add Properties, perform the following:
Select a policy.
Click Properties.
The Mover Properties appear. Click Edit Properties.
In the Properties window, click the Edit Properties field to display a dropdown menu of attributes.
Select one or more attributes for your property.
Click Save.
Create Password Complexity Rules
Password Complexity Rules in a policy ensure that generated passwords adhere to standardized criteria according to defined password policies across automated provisioning workflows. You can define reusable password complexity rules to enforce requirements for password length, mandatory character types (uppercase letters, lowercase letters, numbers, and special characters), and restricted characters when generating random passwords. These rules are available for selection in Sync Identities, Deprovision Identity, and Reset Password actions when working with integrations that support complex password requirements.
To add Password Complexity Rules, perform the following:
Select a policy.
Click Password Complexity Rules.
Click Create Password Complexity Rule.
In the New Password Complexity Rule window, enter a name and the length of the password (default is 6).
Enable the buttons for:
Allow lowercase characters
Allow uppercase characters
Allow numeric characters
Allow special characters
Note: At least numbers, lowercase, or uppercase characters must be allowed.
In the Disallow Character field, enter one or more characters that are not allowed in the password.
Select one or more attributes for your property.
Click Save.
Create Transformer Functions
Custom Transformer Functions allow you to programmatically modify or enrich identity attributes as they are synced from identity sources to target systems. These transformations ensure that data formats align across systems and support more dynamic provisioning logic. Such transformers can:
Convert dates into required formats or perform date-based calculations (e.g., adding days to a hire date).
Normalize or transform string values (e.g., case conversion, trimming, substrings).
Apply conditional logic via functions directly within provisioning rules.
Chain multiple transformations into pipelines for complex workflows.
Be tailored per integration or scenario using custom configurations.
To add Transformer Functions, perform the following:
Select a policy.
Click Transformer Functions.
Click Create Custom Transformer Function.
In the New Custom Transformer Function window, enter a name and description of the transformer. Note: The name of the transformer must start with the dollar sign symbol, $, with snake case and no spaces. For example, $CLEAN_TEXT.
Click the Function Express field to display a dropdown menu of operator functions.
Click Save.
Policy Settings
The Policy Settings page provides information about a specific policy and allows for additional configuration, including:
Modify the primary identity source
Define an additional data source to the primary identity source
Configure email notifications or a webhook for action-related events
Enable continuous synchronization to ensure identities are up-to-date
Set a number of actions for a policy to prevent unexpected issues
Details
The Details pane displays the Policy Name and Description fields. These fields are editable for name change or description refinement, if required.
Primary Identity Source
The Primary Identity Source pane displays the integration name of the data source. The Integration field displays all available data sources, where you can add or remove, if required.
A Primary Identity Source is the authoritative system that serves as the source of truth for user identities (e.g., HR system, Active Directory, identity provider like Okta/Entra ID). Typically, one type of source of identity is associated with one integration.
The role of the Primary Identity Source includes:
Acts as the authoritative record for user information (emails, roles, statuses).
Lifecycle rules such as provisioning, updates, or deprovisioning are typically triggered based on changes detected in this data source.
Ensures consistency and accuracy across target systems where access is granted or revoked.
Additional Identity Sources
As an option, the Additional Identity Sources pane is typically used to add a different type of integration from the Primary Identity Source, which requires that the additional data source be already configured into Lifecycle Management. You can also correlate primary attributes and additional attributes to be associated with the data source. The added data source will sync for authentication, user updates, or provisioning.
To add an Additional Identity Source, perform the following:
Click Add Source.
In the Select Identity Source field, select a data source. Note: If you enable the 'These types are not related' option, then you cannot correlate any attributes.
In the Correlating Attributes pane, select a Primary Attribute from the dropdown menu.
Select an Additional Attribute from the dropdown menu. Note: The Only enrich identity if existing in Primary Identity Source option:
Enabled: Only enriches existing identities from the Primary Identity Source. Does not create new identities.
Disabled: Creates new LCM identities for users found in the Additional Identity Source but not in the Primary Identity Source.
Notifications
When events occur during the execution of a policy’s workflow, notifications can be triggered upon execution of actions in workflows as a means to inform stakeholders or integrate with external systems. These notifications can be optionally configured as their own discrete action in a workflow or as an option when another action is executed. Lifecycle Management supports email- and webhook-based notifications.
For example, an organization might configure its Active Employee policy to send an email to the manager of each new hire after the employee's email address is provisioned. Additionally, a webhook will be sent to the company's learning management system to initiate online onboarding training once each new hire's Okta account is provisioned, following a successful Sync Identity operation.
Use the Notifications to add and manage notifications:
In the Notifications pane, click Add Notification.
Choose the notification type (Email or Webhook).
Choose the event to trigger notifications:
Create Identity
Sync Identity
Add Relationship
Remove Relationship
Create Email
Change Password
Delete Identity
Disable Identity
Manage Relationships
Write Back Email
Access Request Complete
Custom Action
Action Failed
Workflow Task Failed
Extraction Event Failed
Create Entitlement
Create Guest Account
Rename Entitlement
Create Access Review
Reset Password
Create Access Review Queued
Safety Limit Reached
Sync Entitlement
Choose the status to trigger notifications (when an event is Successful, or On Failure).
Select an Existing Veza Action. A Veza Action is an integration with functionality for sending data to external systems, enabling downstream processes around Veza alerts, and access to reviewer actions. Use a Veza Action to configure generic webhooks or enable email notifications.
See Veza Actions on how to create and deploy a Veza Action.
To customize the Webhook setting, perform the following:
In the Webhook URL field, enter the endpoint configured to receive the webhook payload.
In the Webhook Auth Header field, enter the authorization header if the webhook endpoint requires authentication (e.g.,
Bearer token123orAPI-Key abc456).
To customize the Email setting, perform the following:
In the Recipients field, add a recipient name. Use a comma when adding additional names.
In the Recipients From User’s Attributes field, use the arrows to display a list of user attributes. Select one or more attributes that contain email addresses for the email notification.
Click Save.
See Notifications Templates for customizing email notifications.
Advanced Settings
Identity Syncing Option
Identity Syncing at the policy level defines how identities from the authoritative source are synchronized into the target system, including provisioning user accounts or updating existing identities.
The Identity Syncing option controls the behavior of the Sync Identities Actions in a policy workflow, which has Continuous Sync functionality enabled.
Select either:
Sync on changes only - to skip identity syncing when no data source changes are detected
Always sync - to sync, no matter if changes are detected or not
Safety Limits Option
Safety Limits allows you to select the number of actions that can be allowed to run a policy before Lifecycle Management stops the process. This functionality works like a circuit breaker, where the circuit is tripped when a problem occurs. Typically, a number of identities will be updated during the lifecycle process (joiner, mover, leaver); however, if the number of updates seems extremely high compared to expected, then a problem has occurred, and the Safety Limits option prevents further updates to identities.
To set the number of affected identities in Safety Limits, perform the following:
Enable the Safety Limits button.
In the Maximum Number of affected Identities field, use the arrows to set the number of affected identities to the maximum number of changes.
Last updated
Was this helpful?