# Test Policies with Dry Run

## Overview

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

Use dry run testing to:

* Validate that workflow trigger conditions match the intended identities
* Preview what provisioning or deprovisioning actions would occur
* Test policy changes safely before deployment
* Troubleshoot when workflows are not triggering as expected

## Before you start

Before testing with dry run:

* Create or edit a Lifecycle Management policy with at least one workflow
* Ensure your source of identity contains test identities or representative data

## Run a dry run for a single identity

Use single-identity dry run to test how a specific identity would be processed by a policy.

### From a policy

1. Go to **Lifecycle Management** > **Policies**.
2. Select a policy to view its details.
3. Click **Perform Dry Run**.
4. Select an identity to test.
5. Optionally, modify identity attributes to simulate changes (such as a department transfer or status change).
6. Click **Show Results**.

### From an identity

1. Go to **Lifecycle Management** > **Identities**.
2. Search for an identity and click to view its details.
3. Click the **Actions** menu and select **Policy Dry Run**.
4. Select a policy and optionally customize attributes.
5. Click **Show Results**.

## Run a bulk dry run

Use bulk dry run to test a policy against multiple identities at once. You can test against all identities or filter to a specific subset.

1. Go to **Lifecycle Management** > **Policies**.
2. Select a policy and click **Perform Dry Run Bulk**.
3. Choose your identity selection method:
   * **Select All**: Test against every identity in the policy
   * **Select Identities individually**: Choose specific identities from a searchable list
   * **Select Identities based on properties**: Enter a SCIM filter expression to target identities by attribute values (for example, `department eq "Engineering"` or `is_active eq true`)
4. Click **Run Dry Run**.

{% hint style="info" %}
Bulk dry runs may take 8-9 hours to complete for large populations. Focus review on joiner and leaver counts. Investigate unusually high counts (especially leavers) before publishing—this may indicate a misconfigured trigger condition.
{% endhint %}

## Review dry run results

Dry run results show what would happen if the policy ran against the selected identities.

### Matched workflows

The **Workflows Run** section shows which workflows triggered for the identity and why. If no workflows matched, verify that the identity's attributes meet the workflow trigger conditions.

### Planned actions

The **Potential Changes** section lists all actions that would run, including:

* User accounts that would be created or updated
* Attributes that would be synced
* Access profiles that would be assigned or removed
* Relationships (group memberships) that would be added or removed

Click **View Details** on any action to see its full configuration, including sync attributes, relationship mappings, REST payload contents, and password complexity rules.

### Result: 0 changes

When a dry run returns "0 changes", the selected identity does not meet any trigger conditions in the policy's workflows. This is not an error; it means the identity would not be processed by this policy.

## Filter bulk dry run results by attribute changes

When running a bulk dry run, you can filter results to focus on identities where the policy would actually change attribute values. This helps you identify accounts that are out of sync with your policy's desired state, without manually reviewing every identity.

In the bulk dry run results table, use the **Has Attribute Changes** filter dropdown in the filter bar above the results to show only identities where one or more attributes would be modified. The results table shows which attributes would change for each identity. When multiple attributes would change, they appear as tags and collapse to **Attribute Changes (N)** when there are many.

For each attribute that would change, the dry run captures three values:

* **Current Value**: The attribute value that Veza last synced to the target system
* **Current Graph Value**: The value currently observed in the target system (which may have drifted from the last sync)
* **New Value**: The value the policy would write on the next run

Reviewing these three values together helps you understand whether a difference is due to configuration drift, a manual change in the target system, or a policy update — and whether the proposed change is expected.

## View dry run history

Bulk dry run results are preserved in a history table, so you can review previous tests and compare results across multiple runs.

1. Go to **Lifecycle Management** > **Policies**.
2. Select a policy.
3. Click **See Dry Run Bulk History**.

The history shows each dry run task with its filter criteria, identity counts, workflow matches, and timestamps.

## Test disabled workflows

Disabled workflows are evaluated by default during dry run simulations. This means you can test workflow logic before enabling it in production. The dry run results show what actions *would* run if the workflow were enabled.

To learn how to disable workflows, see [Disable workflows and actions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/disable-workflows-and-actions.md).

## Limitations

Dry run has several important limitations:

### What dry run does not evaluate

Dry runs validate trigger and condition matching but **do not evaluate**:

* "First time only" workflow flags (the flag that prevents re-triggering)
* Property change detection (for sync workflows)
* Scheduled triggers
* "Skip if action has already been run" action flags

These behaviors only execute in live policy runs. Test these scenarios with individual identities in a controlled environment before full deployment.

### Integration and action validation

* **No integration testing**: Dry run does not check whether integrations are functioning properly or whether target systems are accessible. A broken integration might cause workflow-defined changes not to be applied when the policy runs.
* **No action validation**: Dry run evaluates whether workflow conditions are met, not whether actions would succeed. It does not validate that changes could be successfully applied.
* **Simulation only**: Dry run identifies actions that would execute but does not perform them.

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

## Best practices

* **Test with representative identities**: Select identities that represent different scenarios (new hires, role changes, terminations) to validate all workflows in your policy.
* **Simulate attribute changes**: Modify identity attributes during dry run to test trigger conditions such as department changes, employment status updates, or location transfers.
* **Test edge cases**: Use dry run to test unusual scenarios that might not occur frequently, such as same-day rehire after termination or simultaneous department and location changes.

### Pre-publish checklist

Before publishing a policy version:

* [ ] Bulk dry run completed for full population
* [ ] Joiner and leaver counts reviewed for anomalies
* [ ] Results compared to expected metrics
* [ ] Lookup table mappings verified for completeness

## See also

* [Lifecycle Management policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md)
* [Disable workflows and actions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/disable-workflows-and-actions.md)
* [Run Dry Run on Identity API](/4yItIzMvkpAvMVFAamTf/developers/api/lifecycle-management/policies/rundryrunonidentity.md)


---

# 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/how-to/test-policies-with-dry-run.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.