Test Policies with Dry Run
Safely preview policy changes and validate workflow logic before enabling policies in production
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
Go to Lifecycle Management > Policies.
Select a policy to view its details.
Click Perform Dry Run.
Select an identity to test.
Optionally, modify identity attributes to simulate changes (such as a department transfer or status change).
Click Show Results.
From an identity
Go to Lifecycle Management > Identities.
Search for an identity and click to view its details.
Click the Actions menu and select Policy Dry Run.
Select a policy and optionally customize attributes.
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.
Go to Lifecycle Management > Policies.
Select a policy and click Perform Dry Run Bulk.
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"oris_active eq true)
Click Run Dry Run.
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.
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.
Go to Lifecycle Management > Policies.
Select a policy.
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.
Limitations
Dry run has several important limitations:
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.
Dry run does not test integration connectivity. Issues like API timeouts, authentication failures, or attribute mapping errors are not detected during simulation.
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.
See also
Last updated
Was this helpful?