> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md).

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

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 consist 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 **Additional Identity Sources** to add more data sources and correlating attributes.
   * Click **Add Source**.
   * Select a source in the **Search Identity Sources** picker.
   * Under **Correlating Attributes**, select an attribute in the **Attribute in** *primary source* column.
   * Select the matching attribute in the **Attribute in** *additional source* column.
   * Click **Add** to add more pairs of correlating attributes.
   * The **Only enrich existing identities** 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.
   * Whether an extraction from this source runs workflows is set per workflow, not on the source. See the **Extraction is processed from** clause in [Create a Workflow](#create-a-workflow).
6. Click **Create**. 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, then open a version from the **Policy Versions** panel.
3. Click **Dry Run** and select **Dry Run with Single Identity**. You can also start this dry run from the **Policies** list: click **⋮** on the policy's row and select **Perform Dry Run**.
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 **Actions Run** section to see all job requests that would be generated (e.g., edits to user attributes, adding/removing access profiles).
   * Check the **Messages** section for evaluation messages.

**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. Open the ⋮ menu and select **Policy Dry Run**.
4. Select a policy, customize entity attributes, and click **Show Results**.

You can also select **Policy Dry Run** from an identity's ⋮ menu in the **Identities** table.

**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. **Duplicate resolution (optional)**: If the policy has a Duplicate Resolution Rule configured, Veza consolidates duplicate records for the same person into a single authoritative identity before triggers evaluate. See [Duplicate Resolution Rules](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/duplicate-resolution.md).
3. **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.
4. **Conditions evaluate**: Conditions within a workflow evaluate sequentially, in the order defined.
5. **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 if this action fails** enabled, or the parent condition has **Continue if any action fails** enabled.

#### Trigger behavior

**"First time only" triggers**

Most workflows (except sync workflows) have **Identity newly matches the condition** selected, so they trigger only when the 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 versus 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:** On the **Policies** page, click the overflow icon (three dots) on a policy's row and select **Enable** to start a policy in the **Initial** state or resume a **Paused** policy, or **Disable** to pause a **Running** policy.

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

Draft mode is a state where a policy is saved but **not yet active**. In 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.

Draft-and-publish is the standard flow for every provisioning policy. There is no setting to turn it on.

**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: on the **Policies** page, click **⋮** on the policy's row and select **Enable**. 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**: Veza Support provides the policy migration script and lookup table files. Contact Veza Support 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 (**Administration > API Keys**).
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 Provisioning Activity approximately 30 minutes after extraction completes.

### Extraction scheduling and policy control

#### Extraction schedules

Extraction frequency for an identity source is set by its extraction interval, which an administrator can change in System Settings. See [How to customize intervals](/4yItIzMvkpAvMVFAamTf/integrations/configuration/extraction.md#how-to-customize-intervals).

To extract at a specific time of day instead, so that identity data is current before a workflow runs, configure a per-data source schedule through the Veza API. There is no UI for this setting, and a schedule replaces the extraction interval for that data source. See [Advanced scheduling](/4yItIzMvkpAvMVFAamTf/integrations/configuration/extraction.md#advanced-scheduling).

#### Workflow parallelism

Concurrency limits apply at the tenant level, across all policies. Set them on the **Performance** tab of the Lifecycle Management **Settings** page:

* **Workflow tasks**: how many triggered workflows run in parallel. Each task runs one identity through its policy workflow.
* **Access request fulfillments**: how many approved requests apply their access changes in parallel.
* **Provisioning jobs**: how many actions Veza sends to connected applications in parallel. Keep this at or above the other two values, or provisioning jobs become the bottleneck.

Raise these values gradually. Higher concurrency adds load to target systems and downstream integrations.

#### 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
   * **Dry Run** - **Perform Dry Run**, **Perform Bulk Dry Run**, and **See Bulk Dry Run History**.
   * **Versions** - **See Version History**, **Discard Draft** (when a draft exists), and **Compare Versions**.
   * **Policy** - **Enable** or **Disable** the policy, or **Delete** it.
4. Click a policy's row to open it. The policy page shows the **Last Policy Run** and **Policy Versions** panels. Open the draft version to create a workflow, transformer, property, password complexity rule, or transformer function. When a policy has more than one version, the **Policy Versions** panel also shows **Compare Versions**. For every control on the policy page and the version page, see [Policy page and version page](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policy-and-version-pages.md).

#### Policy run details

On the policy page, click **View Details** on the **Last Policy Run** panel to open the policy's run details. When a policy draws identities from more than one source, this view covers each source separately. You can also open this view by selecting the status in the **Run Status** column on the **Policies** page.

**Identity Source**

Each source of identity appears as a card under **Identity Source**, showing the data source, the entity type that source contributes, and **Started at** for that source's most recent run. A source with no run history reads **No extractions yet**, and a source with a run in progress shows a running indicator. Select a card to scope the rest of the view to that source.

Veza orders cards by the start time of each source's most recent run, most recent first. Sources with no run history appear last. When the view opens, Veza selects a source that is currently running. If no source is running, Veza selects the source whose most recent run started last.

**Started at** is when Veza began processing that source's most recent run. It is not the time the source last extracted data.

**Run summary**

The summary above the execution steps reads **Current Policy Run** while the selected source is running, and **Last Policy Run** otherwise. It reports the processing time and the policy version. The view shows **Status** only when the run is **Running** or **Stopped**. The **Run Status** column on the **Policies** page also shows **Awaiting** (the policy is waiting for the next extraction) and **Disabled** (the policy is not published to run).

If a safety limit stopped the run, the view shows the alert **Policy run stopped to avoid exceeding safety limit**. Select **View Details** to open the **Blocked Tasks** page.

**Execution steps**

Three steps describe what the run did for the selected source:

* **Analyze Identities** determines which identities changed, validates them against the policy's identity settings, and saves them to Veza. It reports counts of new, deleted, property-changed, and unchanged identities. When valid identity settings are enabled on the policy, it also reports valid and invalid identity counts, and the invalid count links to the matching entries on the **Provisioning Activity** page.
* **Evaluate Workflows** matches identities against workflow trigger conditions and reports how many identities each workflow runs for.
* **Execute Workflows** runs the workflow tasks and reports task counts, completions, errors, and the number of tasks a safety limit held back. Blocked task counts are reported per workflow as well as for the run, so a workflow that reached its own limit is visible individually. The blocked count is a live figure that decreases as tasks are run or abandoned from the **Blocked Tasks** page, and it is included in the total task count. When the run creates no tasks, the step reads **Completed - No tasks to execute**. During a policy's initial run, the step explains that workflows run only after every source of identity has extracted successfully.

For the sequence Veza follows for an individual identity, see [Provisioning Activity](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/activity-log.md#workflow-execution-process).

**Policies with multiple sources of identity**

Each policy run covers one extraction from one source, so sources succeed or fail independently. A failure on one source does not change the status of another, and no combined status is reported across sources.

A policy with more than one source of identity does not process an extraction until every configured source has extracted at least once. Extractions that arrive before then wait. After that, extractions are processed and identities are saved, but workflows do not run until the most recent extraction of every source, primary and secondary, has finished successfully. Workflows start on the extraction after that point. This gate applies once, when the policy first starts: afterward, a failed extraction from one source does not stop workflows for the others.

### **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](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-d0e2262b07a93ba25ea5613605802c9d32169c08%2Fjoiner-workflow-detailed.png?alt=media)

**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](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-78fbfdfcbae29fe4b715e62067b047d05920f609%2Fleaver-workflow-detailed.png?alt=media)

**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 example, 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 before a new employee's start date". To compare a date attribute to the current date, use a `WHEN()` expression. See [Relative Date Conditions with WHEN()](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md#relative-date-conditions-with-when).
* 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. Open the policy, open the draft version from the **Policy Versions** panel, and select the **Workflows** tab.
2. Click **Create** (**Create Workflow** when the policy has no workflows yet).
3. In **Name & Description**, enter the workflow name and description.
4. Use the **Enable Workflow** toggle to set whether the workflow starts enabled.
5. In **Priority**, select one of:

   * Not set
   * Low
   * Normal
   * Medium
   * High
   * Critical

   The levels dictate the order in which workflow tasks run. Higher-priority tasks are processed first. A fairness algorithm prevents lower-priority workflow tasks from being starved.
6. Optionally, configure **Execution Guardrails** (see [Workflow-level guardrails](#workflow-level-guardrails)), then click **Next**.
7. In the workflow editor, click the **Trigger** box to open the trigger panel. Until a condition is set, the box reads **Set Trigger Condition**.
8. Under **Run Workflow**, set the clauses that decide when the workflow runs for an identity:
   * **Extraction is processed from**: select the identity sources whose extractions run this workflow. At least one source is required. Clear a source to update identity attributes from it without running this workflow, for example when an additional source only supplies manager information.
   * **Identity matches this condition**: build the trigger condition string. Once a condition has been set, another conditional string can follow.

     <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>You can also draft the condition string with Access AI. Click <strong>Create with AI</strong> next to the condition field to open a chat thread that suggests a value scoped to this policy and workflow. See <a href="/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/create-with-ai.md">Create with AI for Lifecycle Management</a>.</p></div>
   * **Identity newly matches the condition**:
     * **Selected:** The workflow runs only when the trigger condition is initially met, and on every subsequent transition from "not met" to "met."
     * **Cleared:** The workflow runs on every extraction where the condition is true, regardless of its previous status.
   * **Identity properties**: select **Have changed** or **Run Always**. See [Identity Syncing Option](#identity-syncing-option) for the difference. Under **Have changed**, choose which changes count:
     * **Any property**: a change to any of the identity's properties.
     * **Specific properties**: a change to one or more of the properties selected in **Trigger Properties**. 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). Because this option gates on a *change* to the selected properties, a workflow does not run when its trigger condition first becomes true for a reason unrelated to those properties (for example, a time-based condition such as `hire_date <= TODAY` catching up to an unchanged date). See the [LCM FAQ](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/lcm-faq.md#policy-configuration).
     * **Used properties**: a change to at least one property the workflow actually uses. These are the properties referenced by the trigger condition, enabled conditions, and state-changing actions, plus any you add in **or these properties changed**.
9. (Optional) Under **Workflow Schedule**, click **Add Date Formatter**.
   * Click the **Formatter** field to display a dropdown menu of **operator** functions, the **conditional expression** function, and **attributes**.
   * 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.
10. (Optional) In **Minimum Delay Before Running**, set the delay. 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.
11. Click **Save**.

**Note**: All workflow errors must be resolved before it can be saved.

**Save Conflicts**

When you click **Save** in the workflow editor, Veza checks whether the draft version changed after you opened the editor, for example because another user saved changes to it. If it did, Veza doesn't save. The **Draft Changed Since You Started Editing** dialog opens instead and shows who last edited the draft, when they saved, and when your edit started.

Under **Choose how to resolve**, select an option and click **Confirm**:

| Option                    | Result                                                                                                  |
| ------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Force Save My Changes** | Saves your copy of the draft's workflows, replacing the current draft.                                  |
| **Discard My Changes**    | Closes the editor without saving and returns to the policy version, which shows the latest saved draft. |

To return to the editor with your edits intact, click **Cancel**. Nothing is saved.

{% hint style="warning" %}
**Force Save My Changes** overwrites the draft with your version. The other user's changes are lost.
{% endhint %}

**Clone or Delete a Workflow**

Each workflow card on the version's **Workflows** tab has a menu with these options, alongside **Edit Workflow** and **Workflow Settings**:

* **Clone Workflow** copies the workflow.
* **Delete Workflow** deletes it.
* **Run Workflow Manually** runs the workflow for selected identities in the published version. See [Run workflows manually](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/run-workflows-manually.md).
* **See Notes** displays the workflow notes, when notes exist.

#### 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. Open the policy and open its draft version from the **Policy Versions** panel. If the policy has no draft, click **Create Draft**.
2. Select the **Workflow Components** tab.
3. On the **Transformers** card, click **+**. When the policy has no transformers yet, you can also click **Create 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. For a unique attribute, the **Fallback Formatter** option appears. Click **Add Fallback** to provide an alternative formatter when a conflict occurs if the primary formatter generates a value that is already in use.
13. Optionally, select **Set for new and existing users** to keep the target entity up-to-date with values from the source of truth. The default, **Set for new users only**, sets the value only when the entity is created.
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. Open the policy's draft version and select the **Workflow Components** tab.
2. Select the **Lookup Tables** card.
3. Click **+** on the card. When the policy has no lookup tables yet, you can also click **Create 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. Open the policy's draft version and select the **Workflow Components** tab.
2. Select the **Properties** card.
3. The **Mover Properties** appear. Click **Edit**.
4. In the **Edit Properties** panel, click the **Select options** field to display a dropdown menu of attributes.
5. Select one or more attributes for your property.
6. Click **Save**.

The **Properties** card also holds **Properties for ‘When’ Expressions in Conditions**, which set the date format and time zone for attributes used in `WHEN()` expressions. See [Set the date format and time zone](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md#set-the-date-format-and-time-zone).

#### **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. Open the policy's draft version and select the **Workflow Components** tab.
2. Select the **Password Complexity Rules** card.
3. Click **+** on the card. When the policy has no rules yet, you can also 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. Turn on the toggles for the character types every generated password must include:

   * **Require at least 1 lowercase character**
   * **Require at least 1 uppercase character**
   * **Require at least 1 numeric character**
   * **Require at least 1 special character**

   **Note:** At least one of the lowercase, uppercase, or numeric toggles must be on.
6. In the **Disallow characters** field, enter one or more characters that are not allowed in the password.
7. 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. Open the policy's draft version and select the **Workflow Components** tab.
2. Select the **Transformer Functions** card.
3. Click **+** on the card. When the policy has no transformer functions yet, you can also 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 Expression** 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
* Set execution guardrails that limit how many identities or workflow runs an extraction can affect, 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.

The **Duplicate identity resolution** section of this pane consolidates multiple records for the same person within this source into a single record. See [Duplicate Resolution Rules](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/duplicate-resolution.md).

#### **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. Select a data source in the **Search Identity Sources** picker. **Note:** Leave **'These types are not related'** unchecked (the default) when you want Veza to match identities across both sources using the correlating attributes defined below. Enable the option when the additional source has no correlation to the primary — for example, when adding it purely for enrichment and identity matching is not needed. With the option enabled, Veza hides the **Correlating Attributes** section and skips identity matching between the two sources.
3. In the **Correlating Attributes** section, select an attribute in the **Attribute in** *primary source* column.
4. Select the matching attribute in the **Attribute in** *additional source* column. **Note:** The **Only enrich existing identities** 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) Use the **Duplicate identity resolution** section of the source's card to consolidate multiple records for the same person within this source. Each source carries its own independent rule. See [Duplicate Resolution Rules](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/duplicate-resolution.md).

To update identity attributes from this source without running workflows (for example, when it only supplies manager information from a departmental system), clear the source under **Extraction is processed from** in each workflow. See [Create a Workflow](#create-a-workflow).

#### **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
   * 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
   * Invalid Identities Detected
   * Invalid Identity
   * Identity Metadata Edit
   * Rotate Key
   * Remove Direct Access
   * Identity Deleted From Sources

   The **Manage Relationships** action emits **Add Relationship** and **Remove Relationship** events.
4. Under **Send a notification if:**, choose **Changes were made successfully**, **The action failed**, or both.
5. Select a Veza Action: **Select Veza Action** for a webhook, or **Select Recipient (Veza Action)** for an email. 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.

### **Identity Syncing Option**

This setting controls whether a workflow re-runs for an identity that still matches its trigger condition but whose properties have **not** changed in the source since the last extraction. It takes effect only when the workflow's **Identity newly matches the condition** checkbox is cleared. While that checkbox is selected, the setting has no effect, and the workflow follows first-match trigger behavior instead (see [Trigger behavior](#trigger-behavior)).

It is a **per-workflow** trigger setting, chosen in the workflow editor under **Run Workflow** → **Identity properties**. Each policy also has a default mode. When you publish the policy, Veza saves that default on every workflow that doesn't set its own mode. After that, each workflow keeps its own value, so changing the policy default later affects only workflows added afterward. Policies created in the Veza UI default to **Have changed**. When you create a policy through the API, set `sync_only_when_source_changes` to `true` for the same default. If you omit it, workflows that don't set their own mode publish as **Run Always** with a 24-hour throttle. As with the other [workflow-level guardrails](#workflow-level-guardrails), the policy default is **not** editable in **Policy Settings**.

| Option (under **Identity properties**) | When the workflow runs for a matching identity                                                                                                 | Use when                                                                                                                                                                                                                                                           |
| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Have changed**                       | Only when the identity's properties changed in the source since the last extraction, or when the identity newly matches the trigger condition. | The source emits reliable change events and you want to minimize unnecessary processing.                                                                                                                                                                           |
| **Run Always**                         | Also re-runs matching identities whose properties have **not** changed, subject to a per-identity throttle (below).                            | You want a safety net against missed change events, or the source occasionally produces silent updates that do not trigger change detection. For large tenants, prefer a longer interval: a shorter one re-processes more unchanged identities on each extraction. |

When you choose **Run Always**, a throttle appears: **Unless an unchanged identity already ran in the last** *N* **hours** (default **24 hours**). This is a **per-identity** minimum interval — on each extraction, an unchanged-but-matching identity re-runs only if at least this interval has elapsed since *that identity* was last processed.

{% hint style="info" %}
The throttle is not a separate timer and does not trigger runs on its own. Veza evaluates it during the normal extraction cycle (see [Workflow execution behavior](#workflow-execution-behavior)) — a shorter interval lets each unchanged identity re-run more often, but it does not schedule additional extractions.
{% endhint %}

{% hint style="info" %}
**What counts as a "change"**: Under **Have changed**, a workflow runs for an identity in two cases:

1. One of the identity's attributes changed in the authoritative source since the last extraction.
2. The identity newly matches the workflow's trigger condition (for example, a status attribute changed and the identity now matches an `employed`-only workflow that did not previously apply to it).

A successful workflow run does not repeat for the same identity on subsequent extractions unless attributes change. A failed workflow can retry automatically based on the workflow's **Retry failed workflows** setting (see [Workflow-level guardrails](#workflow-level-guardrails)).
{% endhint %}

To configure:

1. Open the workflow in the policy's workflow editor.
2. Under **Run Workflow** → **Identity properties**, select **Have changed** or **Run Always**.
3. If you selected **Run Always**, set the throttle interval under **Unless an unchanged identity already ran in the last …** (default: 24 hours).
4. Save the workflow.

### **Safety Limits**

Safety Limits guard against unintended mass changes to identities. They stop a policy when an extraction would change, or is changing, more identities than you expect. There are two kinds of limit:

| Limit                   | When it is checked                                        | What it counts                                  |
| ----------------------- | --------------------------------------------------------- | ----------------------------------------------- |
| Predictive Safety Limit | Before any workflow runs for an extraction                | Workflow runs predicted for the extraction      |
| Hard Limit              | Before each workflow task starts, and again while it runs | Identity changes the extraction has made so far |

Each kind can be set for the policy as a whole, for individual workflows, or both. A policy-level limit counts across every workflow in the policy. A workflow-level limit counts only that workflow.

#### Configure safety limits

**Policy-level limits** apply to every workflow in the policy. Click **Policy Settings** on the policy page and go to **Execution Guardrails** → **Safety Limits**:

* **Enable Maximum Changes - Identities** sets the policy-level **Hard Limit** (formerly "Safety Limit"). Enable the toggle, then enter the threshold in the number field next to the helper text **Select maximum number of identities to process**.
* **Enable Maximum Identities - Workflow Run** sets the policy-level **Predictive Safety Limit**. Enable the toggle, then enter the threshold next to the helper text **Select maximum number of workflow runs per extraction**. The minimum is `1`. Although the toggle name says "identities", the threshold counts workflow runs. **Available in Veza v2026.9.7 and later.**

**Workflow-level limits** are part of each workflow's guardrails, described below.

#### Workflow-level guardrails

Each workflow has its own **Execution Guardrails** section on its **Workflow Settings** page. To open it, select **Workflow Settings** from the workflow card's menu on the policy's **Workflows** tab. Workflow-level guardrails apply only to that workflow, allowing different settings for Joiner, Mover, and Leaver workflows within the same policy. The available controls are:

* **Retry failed workflows**: when on, a failed workflow re-attempts on later extractions up to the configured **Max retries** value. The **Max retries** field in the UI accepts values from `1` to `50`; API callers can configure values up to `1000`. When the toggle is off, a workflow that fails on an identity does not re-run for that identity on later extractions, and operators must intervene manually. The corresponding API fields are `no_retry_for_failed_workflow` and `max_retries_for_failed_workflow`; see the [LCM FAQ](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/lcm-faq.md) for the full property table.
* **Block changes when safety limit exceeded** (the per-workflow Hard Limit): the same reactive Hard Limit, counting only this workflow's identity changes. The workflow-level toggle is worded differently from the policy-level one. The accompanying number field shows the helper text **Max identities affected per extraction**.
* **Block workflow run when predicted changes exceed limit** (the per-workflow Predictive Safety Limit): blocks this workflow *before execution begins* if the number of workflow runs predicted for it exceeds the configured threshold. The accompanying number field shows the helper text **Max identities per workflow run**, but the threshold counts workflow runs, not identities. Use it to stop unintended mass processing when upstream attribute changes in a Source of Identity would trigger a large batch of Joiner, Mover, or Leaver runs.

{% hint style="info" %}
**Policy-level and workflow-level limits are independent.** A workflow uses only its own guardrail values. It does not fall back to the policy's values, and the policy-level limits are checked separately, in addition to each workflow's own. Retry is configured only per workflow.
{% endhint %}

#### When a safety limit is reached

For each extraction, Veza checks the limits in this order:

1. **Policy-level Predictive Safety Limit.** If the predicted workflow runs across all workflows exceed it, every workflow's tasks for the extraction are blocked, and the workflow-level predictive checks are skipped.
2. **Workflow-level Predictive Safety Limits.** Each workflow is checked on its own. A workflow over its limit has all of its tasks blocked. The other workflows' tasks run normally.
3. **Hard Limits, as tasks run.** Before each task starts, and again while it runs, Veza checks the policy-level Hard Limit and then that workflow's own Hard Limit. When the policy-level count is reached, every remaining task in the policy is blocked, whichever workflow it belongs to. When a workflow-level count is reached, only that workflow's remaining tasks are blocked. A task blocked partway through keeps its progress, and continues from that point if you run it.

Whichever limit is reached:

* The blocked tasks wait on the [Blocked Tasks](#blocked-tasks) page until an administrator runs or abandons them.
* **The whole policy stops processing extractions.** This applies to a workflow-level limit too. Later extractions are skipped for every workflow in the policy, not queued, until an administrator resumes processing. Skipped extractions are not replayed, but their changes are not lost. When processing resumes, the next extraction compares the current source data with the identities Veza stored before the limit was reached, so identities that changed, appeared, or were removed in the meantime are detected. Veza sees only the net result: an attribute that changed and then changed back counts as unchanged. If the source has not changed since the most recent skipped extraction, the changes are detected on the next extraction in which the source data changes.
* Veza records a `SAFETY_LIMIT_REACHED` event. Its message says which limit was reached, and names the workflow for a workflow-level limit.

{% hint style="info" %}
**Example: the Leaver workflow reaches its own limit.** Leaver's tasks from that extraction are blocked. Joiner and Mover tasks from the same extraction still run. From then on, the policy skips later extractions for all three workflows until the blocked tasks are resolved and processing is resumed. To stop every workflow as soon as the limit is reached, set the limit at the policy level instead.
{% endhint %}

{% 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 %}

#### Blocked Tasks

The **Blocked Tasks** page lists the tasks a safety limit held back. For a task, or a selection of tasks, you can:

* **Run** the blocked tasks (manually approve execution)
* **Abandon** the blocked tasks (discard without executing)

To restart the policy, click **Resume Processing Extractions**, then **Confirm and Resume**. Any tasks still blocked are run, and the policy processes extractions again. To discard the remaining tasks instead, abandon them before you resume.

### **Identity Validation**

Identity Validation evaluates each identity against [SCIM filter expressions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md) before workflows run, and halts the extraction when too many identities fail. It is a threshold control for the run as a whole, not a per-identity filter:

* While the invalid count stays within the configured tolerance, identities marked invalid are still saved and still processed. Validation records them; it does not exclude them. The default tolerance is 0, so a single invalid identity stops the extraction.
* Once the invalid count exceeds the tolerance, the entire extraction stops before any identities are saved, and the policy does not process further until an operator reviews the results.

Use Identity Validation when an upstream source is occasionally noisy — for example, when staging records or partially provisioned identities appear in the authoritative feed and should not trigger Joiner or Leaver actions.

To configure:

1. Open the policy, click **Policy Settings**, and go to **Execution Guardrails**.
2. Under **Identity Validation**, toggle **Enable Identity Validation** on.
3. In **Valid Identity Filter**, enter a SCIM filter expression that all valid identities must match. Identities that do not match are marked invalid.
4. In **Invalid Identity Filter**, enter a SCIM filter expression that explicitly identifies invalid identities. Identities matching this filter are marked invalid even if they also match the valid filter.
5. Set **Max Invalid Events** to cap the number of `INVALID_IDENTITY` activity log entries Veza records per extraction. Default: **1000**. The total invalid count is always tracked accurately — this field only limits event log volume.
6. Set **Max Invalid Allowed to Proceed** to the highest invalid count the policy can tolerate before halting. Default: **0** (strict — any invalid identity blocks the run). Set to a non-zero number to allow up to that many invalid identities before the policy stops.
7. Save the policy.

**Filter semantics:** An identity is marked invalid if it matches **Invalid Identity Filter** OR fails to match **Valid Identity Filter**. If only one filter is configured, only that filter is evaluated.

A filter that cannot be evaluated for an identity counts as not matching, so for **Valid Identity Filter** the identity is marked invalid. A filter that cannot be parsed at all causes the extraction to fail. Veza does not check filter syntax when the policy is saved, so test filter expressions first.

**Example filters:**

| Goal | Filter |
| ---- | ------ |

\| Require an email and a first name | `email ne null and (first_name ne null or beeline.first_name ne null)` | | Exclude identities tagged as test accounts | Set **Invalid Identity Filter** to `tags co "test_account"` |

Filters use the standard Veza SCIM filter syntax — see [Trigger Conditions Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md) for the operator reference.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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 following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

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.