Conditions and Actions

When creating Lifecycle Management Policies, you can configure workflows that define actions to execute during different employment lifecycle scenarios, such as when an employee is onboarded, changes function or role, or is withdrawn from the organization. Actions can be executed in sequence based on specific conditions, enabling you to automate onboarding and offboarding actions within Lifecycle Management, across systems in your environment.

Understanding Policies, Workflows, and Actions

Policies and workflows define how Veza automates identity management tasks across your environment by describing conditional actions to execute for different employee populations.

Policies

• Define the overall automation framework for managing identities throughout their lifecycle

• Specify which source of identity triggers the automation

• Can contain multiple workflows to handle different scenarios (joiner, mover, leaver)

• Support continuous synchronization to keep identities up-to-date

Workflows

• Define specific sequences of actions that execute based on trigger conditions

• Handle different lifecycle scenarios (e.g., new hire onboarding, role changes, terminations)

• Support conditional execution based on user attributes (department, location, role, etc.)

• Allow for complex decision trees through nested conditions

Conditions

• Define when specific actions should occur within a workflow

• Can be based on any attribute from the source of identity

• Support SCIM filter expressions for precise targeting

• Can be nested to create sophisticated logic trees

Example Conditions for Lifecycle Management Actions:

• Add to engineering groups based on department: department eq "Engineering"

• Grant manager access based on role: is_manager eq true

• Assign cost center groups: cost_center eq "IT-1234"

Actions

• Represent specific tasks such as creating users, syncing attributes, or managing access

• Types of actions include:

  • SYNC_IDENTITIES: Create/update user accounts

  • MANAGE_RELATIONSHIPS: Grant/revoke access

Example Conditions and Actions: Provisioning to Active Directory

The following workflow configuration for a Lifecycle Management Policy enables provisioning actions for Active Directory users when workers are added in Workday:

• Create an Active Directory user, synchronizing attributes with the source Workday Worker

• Create email addresses for new employees in Exchange Server

• Update the Workday Worker and AD User records to include the new email

• Grant entitlements by assigning Access Profiles according to the Worker's department

Sync Active Directory Accounts for Active Employees (Joiners/Movers)

When provisioning users, Veza synchronizes attributes for active employees and creates them during AD User provisioning. These attributes can be transformed from attributes in the source of identity (Workday):

Sync Active Directory Attributes for Withdrawn Employees (Leavers)

To de-provision users, Veza moves accounts to a terminated users group and adds them to an OU for terminated employees:

• Moving leavers into a "Terminated Users" group (via the primary_group_dn attribute) effectively restricts access to systems that rely on Active Directory for authentication and authorization

• Updating the distinguished_name to place leavers in a specific organizational unit (OU) like "Evergreen Termination" separates active users from inactive ones and enables the application of policies, scripts, and queries that target inactive users without affecting active employees

Action Types

Note on Action Hierarchy: The "Sync Identities" action is the only action type that can be declared at the root condition level. All other actions (such as Manage Relationships, Create Email, etc.) must be defined within sub-conditions after establishing a root condition with "Sync Identities". The UI enforces this hierarchy and will show a warning when adding non-Sync actions at the root level.

Sync Identities

Synchronizes identity attributes between systems, with options to:

• Create new identities if they don't exist

• Update attributes of existing identities

• Enable continuous sync to keep attributes aligned with the source of truth

Example Use Cases:

• Create new user accounts in target systems when employees join

• Update user attributes when information changes in HR systems

• Ensure consistent user information across multiple platforms

Manage Relationships

Controls entitlements such as group memberships and role assignments for identities.

Example Use Cases:

• Add users to appropriate security groups, roles, permission sets, or other access-grant entities

• Remove users from groups during role changes

• Update entitlements when employees move between departments

Create Email

Integrates with an email provider to create email addresses for identities. This action is often used in combination with other actions in new hire and temp-to-hire workflows.

Example Use Cases:

• Create corporate email accounts for new employees

• Establish shared mailboxes for teams or projects

Deprovision Identity

Safely removes or disables access for identities when they withdraw from the organization.

Example Use Cases:

• Disable accounts when employees or contractors leave

• Revoke access while maintaining audit records

• Transition resources and non-human identities when owners depart

Write Back Email

Updates HRIS or other systems with email addresses created in other actions.

Example Use Cases:

• Update employee records with newly created email addresses

• Sync email information back to master HR systems

• Ensure consistent email records across all platforms

Pause

Introduces a deliberate delay in the workflow execution.

Example Use Cases:

• Allow time for system propagation between actions

• Implement rate limiting in multi-step workflows

• Coordinate timing with external processes

Send REST Request

Makes HTTP requests to external APIs and services as part of provisioning workflows. This action enables integration with custom applications, webhooks, and REST-based services that support identity management operations.

Example Use Cases:

• Notify external systems when users are created or updated in target systems

• Trigger custom provisioning workflows in third-party applications

• Send identity data to SCIM endpoints for user synchronization

• Create service desk tickets for manual provisioning steps

Variable Substitution:

Both the webhook URL and JSON payload support attribute transformation using curly brace syntax. Identity attributes from the source system can be dynamically inserted into requests:

Available transformations include UPPER, LOWER, TRIM, and accessing nested attributes with dot notation, such as {Manager.email}. See for complete transformation syntax.

Note: If any placeholder in the URL or payload cannot be resolved (e.g., due to missing attributes), the entire transformation is skipped and the original URL is used without any substitution. The system logs a warning for troubleshooting. Ensure all referenced attributes exist in the source of identity to enable proper variable substitution.

Response Handling:

When "Add Response to Output Entities" is enabled, the action parses JSON responses and extracts specified entity data. This enables chaining actions where one API call creates a resource and returns an identifier that subsequent actions can reference.

For example, if a user creation API returns:

Configure the action with:

• Response Entity Attribute: result

• Response ID Attribute: user_id

• Response Name Attribute: display_name

The extracted entity becomes available to downstream workflow actions.

HTTP Method Guidelines:

• GET: Query operations, typically without payload; use for checking resource state or retrieving data. Does not set workflow change flags

• POST: Create new resources; requires JSON payload; sets both AnyCreated and AnyChanges flags that can trigger downstream actions with "Only Send if Any Upstream Changes" enabled

• PUT: Replace entire resources; requires JSON payload; sets AnyChanges flag

Workflow Integration: The AnyCreated and AnyChanges flags enable conditional workflow execution. Actions configured with "Only Send if Any Upstream Changes" will only execute when a previous action has set these flags, allowing you to build sophisticated conditional workflows (e.g., only send a notification webhook if a user was actually created, not just updated).

Authentication Patterns:

The authorization header supports common authentication methods:

• Bearer Token: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

• API Key: X-API-Key: secret-key-123 or Authorization: ApiKey sk-prod-xyz

• Custom Headers: Any header format your API requires

Limitations:

• Only JSON payloads are supported (no XML, form-data, or other formats)

• Authentication must be header-based (OAuth flows requiring user interaction are not supported)

• Response parsing requires valid JSON if "Add Response to Output Entities" is enabled

• Timeout applies to entire request; no automatic retry on failure

Send Notification

Triggers email notifications and webhooks based on lifecycle events and action success or failure. Notifications can be added to any action type under Edit Action > Action Notification Settings.

Example Use Cases:

• Alert IT staff when provisioning is complete

• Notify managers of access changes

• Create a service desk ticket for any manual steps

• Send standardized notifications using custom templates across workflows

Email Template Selection:

When configuring email notifications (either as a Send Notification action or in Action Notification Settings), you can choose which template to use:

• Default template: Uses the built-in event-specific template based on the lifecycle event being processed

• Custom template: Uses a reusable custom email template you've created, allowing consistent messaging across multiple workflows

Custom templates support the same placeholders as event-specific templates, enabling dynamic content like identity names, workflow names, and action results. See for placeholder reference and template management.

Reset Password

Resets user passwords in target systems. Configuration options and behavior vary by integration.

Example Use Cases:

• Reset passwords for new users who must change on first login

• Enforce password rotation policies

• Recover from account lockouts

Supported Integrations: