# Policies

### **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:

1. Go to **Policies**.
2. Click **Create Policy**.
3. 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
4. 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](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/integrations.md) 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).

   <div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><p><strong>OAA template restriction for Source of Identity</strong>: When using an OAA custom provider as a Source of Identity, only providers configured with the <strong>HRIS</strong> or <strong>Identity Provider (IdP)</strong> template type are eligible. Providers using the Application or Principal template types can serve as provisioning targets but cannot be used as identity sources. No additional provider needs to be created if an existing HRIS or IdP OAA provider is already configured.</p></div>
5. (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.
   * The **Skip Workflow Runs on Extraction** option controls whether workflows are triggered when this identity source is extracted:
     * **Enabled**: Updates identity attributes from this source without running workflows. Use this when you want to enrich identities with supplementary data but don't need provisioning or deprovisioning actions to run.
     * **Disabled** (default): Workflows run normally when extractions occur from this source.
6. 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:

1. Go to **Policies**.
2. Click a policy to view its details.
3. Click **Dry Run Policy** at the top right.
4. Choose the identity and policy to test workflows.
5. Select one or more attributes to sync. You can modify attributes to simulate potential changes.
6. Click **Show Results**.
7. 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:

1. Go to **Identities**.
2. Search for an identity and click to view its details.
3. Expand the Actions menu at the top right and click **Policy Dry Run**.
4. 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

{% hint style="info" %}
Dry Run does not test integration connectivity. Issues like API timeouts, authentication failures, or LDAP attribute mapping errors will not be detected during simulation.
{% endhint %}

**Best Practices**

Use Dry Run to validate that policies and their workflows are working as intended before enabling them in a live environment.

1. **Test with Representative Identities:** Select identities that represent different scenarios (new hires, role changes, terminations) to validate all workflows in your policy.
2. **Simulate Different Scenarios:** Modify identity attributes during Dry Run to test trigger conditions such as:
   * Department changes
   * Employment status updates
   * Location transfers
   * Role modifications
3. **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

### Workflow execution behavior

Understanding how workflows execute helps with troubleshooting and policy design.

#### Execution order

When identity source data changes, Veza processes it in this order:

1. **Extraction completes**: Data is pulled from the identity source.
2. **Workflow triggers evaluate**: Veza begins evaluating trigger conditions within approximately 1 second of extraction completing. Actual evaluation time scales with the number of managed identities. Policies with thousands of identities can take several minutes to process. For policies with multiple identity sources, evaluation waits until all configured sources have completed extraction.
3. **Conditions evaluate**: Conditions within a workflow evaluate sequentially, in the order defined.
4. **Actions execute**: Actions within a condition execute in order. If an action fails, the remaining conditions in the workflow are skipped and the workflow is marked as errored — unless the failing action has **Continue on Error** enabled, or the parent condition has **Continue Actions if Any Error** enabled.

#### Trigger behavior

**"First time only" triggers**

Most workflows (except sync workflows) are configured to trigger "only when trigger condition is first met." This means:

* The workflow triggers the first time an identity matches the condition.
* If the condition clears (identity no longer matches) and then matches again, the workflow triggers again as if it were the first time.
* This behavior handles rehire scenarios where a previously terminated employee returns.

**Sync workflows**

Sync workflows track specific properties for changes. When adding new properties that require syncing:

* Update the tracked property list in the workflow configuration.
* Update sync-related common transformers to include the new attributes.

For more information on workflow triggers, see [Trigger Conditions Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md).

#### SCIM condition limitations

Trigger conditions use SCIM filter syntax. When comparing values, only the variable on the **right side** of the comparison can be transformed. The left side must be an attribute reference without transformation. See [Trigger Conditions Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md) for syntax details.

### **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:

1. On the **Lifecycle Management Dashboard** page, click **Settings** in the top menu.
2. The Lifecycle Management Settings page appears. Click **Policy Settings**.
3. 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:

1. Create and save a new policy.
2. Create a new workflow and **Save**.
3. After creating a new workflow, click **Publish**.
4. 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.
5. Click the overflow menu (three dots) and select **Perform Dry Run** to test your workflow.
6. 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.
7. Click **Edit Workflow** to make changes to your workflow.
8. Continue to modify your workflow using the previous steps until your workflow displays the expected results. Click **Publish**.
9. 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.

### Migrating policies between environments

For organizations using multiple Veza tenants (such as sandbox and production), policies can be migrated between environments using migration scripts provided by Veza support.

{% hint style="info" %}
**Migration script availability**: The policy migration script and lookup table files are provided by Veza support. Contact [support.veza.com](https://support.veza.com) to request the migration toolkit for your deployment.
{% endhint %}

#### When to use migration scripts

Use the migration script approach for:

* Large policies with many workflows and complex transformers
* Repeated migrations between the same environments (sandbox → production)
* Policies where manual reconstruction would be time-consuming

For simple policies or one-time migrations, manual reconstruction may be faster than setting up the migration toolkit.

#### Environment setup (one-time)

1. In both sandbox and production tenants, log in as an Integration Manager or Administrator and create API keys (**Integrations > API Key**).
2. Store each key in a password manager or secrets vault.
3. Set environment variables for the migration script:
   * `VEZA_TOKEN` for production
   * `VEZA_TOKEN_2` for sandbox
4. Set up a Python virtual environment for running migration scripts.
5. Obtain the migration script and lookup table files from Veza support.

#### Migration procedure

1. In the target tenant, create a new draft version of the policy and note the version number.
2. If any of the following changed since the last migration, update the lookup table CSV (provided by support) with new IDs:
   * Access Profiles
   * Email Templates
   * Webhook notifications
3. Update the migration script configuration with source and target version numbers.
4. Run the migration script.
5. Review the migrated policy and apply any manual corrections needed.
6. Run a bulk dry run (allow 8-9 hours for completion).
7. Review joiner and leaver counts—high counts may indicate configuration issues.
8. Publish the policy and wait for the next extraction to verify correct execution.
9. Review the Activity Log approximately 30 minutes after extraction completes.

### Extraction scheduling and policy control

#### Extraction schedules

Extraction schedules for identity sources are configured via the Veza API. To modify extraction frequency or timing, contact [Veza Support](https://support.veza.com) for assistance with API configuration.

#### Workflow parallelism

The maximum number of concurrent workflows is configured at the tenant level via API. This setting controls how many workflow jobs can run simultaneously across all policies. Contact [Veza Support](https://support.veza.com) to adjust concurrency limits for your deployment.

#### Policy pause behavior

Disabling a policy pauses any running workflows. Re-enabling the policy does **not** resume paused workflows—they restart on the next extraction cycle.

### **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.

{% hint style="info" %}
A policy can be enabled without any workflows configured. This allows the **Identities** table to begin populating from the connected identity source immediately, which is useful for validating identity data before building out provisioning workflows.
{% endhint %}

{% hint style="info" %}
Publishing or updating a policy does not automatically trigger an extraction. To apply policy changes immediately, manually trigger an extraction from the **Integrations** page.
{% endhint %}

To manage policies on the main **Policies** overview:

1. Go to **Lifecycle Management > Policies**
2. Find the policy you want to manage
   * Search for a specific **policy by name**
   * Filter to show all providers by their **current state**
3. 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.

#### **Example Workflows**

The following diagrams illustrate typical joiner and leaver workflow implementations, showing how identity changes in your HR system trigger coordinated provisioning and de-provisioning actions across multiple target applications.

**Joiner Workflow**

When a new employee is created in Workday, Veza automatically provisions accounts and assigns appropriate access across connected systems based on the employee's role and attributes.

![Lifecycle Management joiner workflow showing user creation, attribute sync, and account provisioning steps](/files/hxMzVZNN3LhwBNgd3rjt)

**Leaver Workflow**

When an employee's status changes to inactive or terminated in Workday, Veza automatically de-provisions accounts and removes access to protect your organization's security posture.

![Lifecycle Management leaver workflow showing user deactivation, account disabling, and access removal steps](/files/gR94yhT8TCPPb3X9FBTe)

**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. Trigger conditions use **SCIM filter syntax** to evaluate whether an identity matches specific criteria.

See [Trigger Conditions Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md) for SCIM filter syntax and available operators, or [Attribute Mapping](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/attribute-mapping.md#example-usage) for a comparison with transformer syntax.

* Trigger conditions 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:

1. Select a policy.
2. Click **Create Workflow**.
3. In **Details**, enter the workflow name and description.
4. 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.

1. In the **New Workflow** pane, click **trigger attribute**. The **Edit Workflow** pane appears.
2. In the **Triggering Condition (Condition String)** 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.
3. In the **Options** section, select one of the following:
   * **Run only when trigger condition is first met** -
     * **If Enabled:** The workflow executes only when the trigger condition is initially met, and on every subsequent transition from "not met" to "met."
     * **If Disabled:** The workflow runs on every check where the condition is true, regardless of its previous status.
   * **Run only if specific properties change** - This workflow is conditionally triggered for an identity when a change is detected in one or more of its specified properties. When enabled, the Properties field appears. For more precise control (such as triggering only when two specific properties change together) use `sys_attr_changed__<property>` attributes directly in the trigger condition string instead. See [System Attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/system-attributes.md#sys_attr_changed__property).
4. In the **Properties** field, select a property attribute from the dropdown menu. As the defining attributes of identities, accounts, and entitlements, properties furnish the data points upon which a policy can base its action-oriented logic.
5. In the **Date Formatters**, click **Add Date Formatter**.
6. Click the **Formatter** field to display a dropdown menu of **operator** functions, the **conditional expression** function, and **attributes**.
7. Click the **Then Apply** field to display a dropdown menu of operator functions. The **Then Apply** field combines a series of attribute formatters with the pipe (|) character to run the value of an attribute in sequence. The output of one formatter becomes the input of the following formatter.
8. In the **Minimum Delay Before Running** field, set the delay in **hours**, **minutes**, and **seconds**. This option prevents actions from executing immediately when a trigger condition is met. The purpose of such a delay is usually to allow for propagation or to prevent repeated rapid changes that trigger unintended cycles.
9. Click **Save Workflow**.

**Note**: All workflow errors 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.

#### Common workflow patterns

**Webhook notifications after Sync Identity**

For ITSM integrations that need to receive all attributes after a Sync Identity action completes:

1. Place the webhook action under a condition that follows the Sync Identity action in the workflow tree.
2. Add a pause action before the webhook if needed to allow time for attribute propagation.
3. Use clear naming conventions for conditions (for example, "FTE New Hire AD Notification") to indicate their purpose.

#### **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:

1. Select a policy.
2. Click **Transformers**.
3. Click **Add Transformer**.
4. In the **New Transformer** window, enter a transformer name and description.
5. Click the **Integration** field to display a dropdown menu of integrations of a target system.
6. Click the **Entity Type** field to display target entity types based on the integration that was previously selected.
7. In **Attributes**, click **Add Attribute**.
8. In Unique Identifier, click the Destination Attribute field to display a list of attributes.
9. Click the **Formatter** field to display a dropdown menu of operator functions, the Conditional Express function, and attributes.
10. Click the **Then Apply** field to display a dropdown menu of operator functions. The **Then Apply** field combines 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.
11. Optionally, click **Add Attribute** to add more attributes and repeat the attribute steps.
12. 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.
13. Optionally, enable the **Continuous Sync** function to keep the target entity up-to-date with values from the source of truth.
14. Click **Save**.

See [Transformer Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/transformer-reference.md) 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:

```csv
location_code,state_code,state,city
MN001,MN,Minnesota,Minneapolis
CA001,CA,California,Los Angeles
TX001,TX,Texas,Houston
TX002,TX,Texas,Austin
```

Once 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](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/lookup-tables.md) for detailed information.

To add a **Lookup Table,** perform the following:

1. Select a policy.
2. Click **Lookup Table**.
3. Click **Add Lookup Table**.
4. In the **New Lookup Table** window, enter a name and description for the Lookup table.
5. Drag and drop a CSV file or navigate to a CSV file to upload. The CSV file must be 10MB or less.
6. After uploading the file, you can preview it.
7. 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:

1. Select a policy.
2. Click **Properties**.
3. The **Mover Properties** appear. Click **Edit Properties**.
4. In the **Properties** window, click the **Edit Properties** field to display a dropdown menu of attributes.
5. Select one or more attributes for your property.
6. 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:

1. Select a policy.
2. Click **Password Complexity Rules**.
3. Click **Create Password Complexity Rule**.
4. In the **New Password Complexity Rule** window, enter a name and the length of the password (default is 6).
5. 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.
6. In the **Disallow Character** field, enter one or more characters that are not allowed in the password.
7. Select one or more attributes for your property.
8. 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:

1. Select a policy.
2. Click **Transformer Functions**.
3. Click **Create Custom Transformer Function**.
4. 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.
5. Click the **Function Express** field to display a dropdown menu of operator functions.
6. 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

{% hint style="info" %}
Making changes in the **Policy Settings** page will impact all versions (Draft, Published, and Retired) of the policy.
{% endhint %}

{% hint style="info" %}
\*\*Policy JSON Viewer\*\*: When enabled, a "Show Raw JSON" button appears in policy header actions to export complete policy configurations for debugging and technical support. See \[LCM FAQ]\(lcm-faq.md) for details.
{% endhint %}

#### **Details**

The **Details** view shows 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.

{% hint style="info" %}
You can add multiple Primary Identity Sources if they are the same type of integration. If a different type of integration is required, use the Additional Identity Source.
{% endhint %}

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:

1. Click **Add Source**.
2. 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.
3. In the **Correlating Attributes** pane, select a **Primary Attribute** from the dropdown menu.
4. 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.
5. (Optional) Enable **Skip Workflow Runs on Extraction** to update identity attributes from this source without triggering workflows. This is useful when you want to enrich identities with supplementary data (such as manager information from a departmental system) but don't need provisioning or deprovisioning actions to run each time this source is extracted.

#### **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:

1. In the **Notifications** pane, click **Add Notification**.
2. Choose the notification type (**Email** or **Webhook**).
3. 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
4. Choose the status to trigger notifications (when an event is **Successful**, or **On Failure**).
5. 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](/4yItIzMvkpAvMVFAamTf/administration/administration.md) on how to create and deploy a Veza Action.
6. 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 token123` or `API-Key abc456`).
7. 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.
8. Click **Save**.

See [Notifications Templates](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.md) 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**

Safety Limits prevent unintended mass changes to identities by enforcing configurable thresholds. Two independent mechanisms are available and can be used together for layered protection:

**Hard Limit**

The **Hard Limit** (formerly "Safety Limit") is a reactive mechanism that stops processing *during execution* once the configured number of identity changes has been reached. When the limit is triggered, no further identity changes are processed for the current policy run.

To configure a Hard Limit:

1. Enable the **Hard Limit** toggle.
2. Set the **Maximum Number of Affected Identities** to define the threshold.

{% hint style="info" %}
**Parallel execution and Hard Limits**: When a policy processes tasks in parallel, the total number of completed changes may slightly exceed the configured Hard Limit. This is because multiple tasks that are already in progress can complete before the system detects that the threshold has been reached. The amount of overshoot depends on the number of tasks allowed to run at the same time. Once the overshoot is detected, all remaining tasks are blocked for manual review.

To enforce the Hard Limit exactly with no overshoot, set the parallel task count to 1. This ensures each task completes before the next one begins, at the cost of longer processing times.
{% endhint %}

**Predictive Safety Limit**

The **Predictive Safety Limit** is a proactive mechanism that blocks all changes *before execution begins* if the system predicts the number of workflow runs will exceed configured thresholds. This prevents unintended mass processing of identities when upstream attribute changes in a Source of Identity would trigger unnecessary Joiner, Mover, or Leaver workflows.

To configure a Predictive Safety Limit:

1. Enable the **Predictive Safety Limit** toggle.
2. Set the **Maximum Number of Workflow Runs** to define the threshold.

**Workflow-Level Limits**

Safety limits can be configured at both the policy level and individual workflow level for granular control. When configured at the workflow level, each workflow enforces its own thresholds independently, enabling different limits for Joiner, Mover, and Leaver workflows within the same policy.

**Blocked Tasks**

When a Predictive Safety Limit triggers, no changes are processed. A warning appears on the **Blocked Tasks** page with options to:

* **Review** what would have changed
* **Run** the blocked tasks (manually approve execution)
* **Abandon** the blocked tasks (discard without executing)

Processing of future extractions is paused until the administrator acknowledges the warning and resumes processing. New activity log event types `PREDICTED_SAFETY_LIMIT_EXCEEDED` and `WORKFLOW_PREDICTED_SAFETY_LIMIT_EXCEEDED` are recorded when predictive limits trigger.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.