Policies

Create and manage automated provisioning policies with conditions and actions for identity lifecycle

Lifecycle Management Policies enable automated identity lifecycle processes through rule-based workflows. These APIs allow you to create, manage, and test policies that govern how identity attributes trigger actions across systems, enabling automated workflows for employee lifecycle events like onboarding, role changes, and offboarding.

These APIs provide ways to:

• Create automated provisioning and deprovisioning workflows

• Configure conditional logic based on identity attributes

• Define actions that execute when workflow conditions are met

• Test policy configurations against specific identities without making changes

• Manage policy states and versioning for controlled deployments

Policy Concepts

A Lifecycle Management Policy consists of two main components:

1. Base Policy - Contains metadata such as name, description, state, and data source information

2. Policy Configuration - Contains the workflows, conditions, and actions that define how the policy operates

Policies are versioned, allowing for change management and testing of configurations before deployment.

Policy States

Policies can be in different operational states:

INITIAL

Newly created policy, not yet active. Use this state when first creating policies to configure them before activation.

DRY_RUN

RUNNING

PAUSED

Endpoints

Use the following endpoints to interact with Lifecycle Management Policies:

Policy Management Operations

Method	Endpoint	Description
GET	List Policies	Retrieves all lifecycle management policies
POST	Create Policy	Creates a new lifecycle management policy
GET	Get Policy	Retrieves a specific policy by ID
PATCH	Update Policy State	Updates the operational state of a policy

Policy Configuration Operations

Method	Endpoint	Description
PATCH	Update Policy Configuration	Updates the complete configuration of a policy version
POST	Add Condition to Policy	Adds a condition to a specific workflow in a policy
POST	Add Action to Policy	Adds an action to a specific condition in a workflow

Policy Testing Operations

Method	Endpoint	Description
POST	Run Dry Run on Identity	Tests policy execution against a specific identity without making changes

Policy Workflow Structure

Policies contain workflows that define:

• Trigger Conditions - SCIM filter expressions that determine when the workflow activates

• Success Conditions - Additional conditions evaluated when the trigger is met

• Actions - Operations executed when conditions are satisfied

• Transformers - Optional attribute transformations

Authentication

All Policy API requests require authentication. See API Authentication for details on how to authenticate with Veza APIs.

Getting Started

To get started with Policy APIs:

1. Create a policy with basic metadata and datasource information

2. Update the policy configuration to define workflows, conditions, and actions

3. Test with a dry run to verify the policy works as expected

4. Update the policy state to activate the policy for production use

For a comprehensive example of policy configuration, see the Update Policy Configuration documentation.

Policy Migration Between Environments

When moving policies between environments (e.g., sandbox to production), you can export and import policy configurations using the API endpoints.

Export a Policy

1. Get the base policy information:

   GET /api/private/lifecycle_management/policies/{policy_id}

2. Extract the current policy configuration:

   From the response, use the current_version.config object which contains the complete policy logic including workflows, conditions, actions, and transformers.

Import to New Environment

1. Create the base policy in the destination environment:

   POST /api/private/lifecycle_management/policies

2. Update the policy configuration with your exported configuration:

   PATCH /api/private/lifecycle_management/policies/{new_policy_id}/versions/{version_number}

When moving policies between environments, you'll need to update:

• Access Profile IDs referenced in actions

• Datasource IDs that may differ between environments

• Any environment-specific attribute values or conditions

Migration Best Practices

• Test First: Always set the imported policy to DRY_RUN state initially to test in the new environment

• Verify IDs: Ensure all referenced Access Profile IDs and datasource IDs exist in the target environment

• Update Conditions: Review trigger strings and condition strings for environment-specific values

• Gradual Activation: Move from DRY_RUN → INITIAL → RUNNING to ensure proper testing

Related Documentation

For more information about Policy concepts and features, see:

• Policies and Workflows

• Actions

• Attribute Transformers

• Access Profile APIs