Conditions and Actions

Configure the conditions and actions that execute when workflows run.

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

• Enable email notifications and webhooks for action-related events

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

• Execute actions in a defined order when conditions are met

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

• Can trigger multiple actions when met

• Can spawn additional conditions after successful action completion

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"

• Add to contractor AD groups: employment_type eq "CONTRACTOR"

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

  • CREATE_EMAIL: Generate email addresses

  • DEPROVISION_IDENTITY: Disable/remove access

  • DELETE_IDENTITY: Permanently delete accounts

  • CUSTOM_ACTION: Integration-specific operations (e.g., ServiceNow table inserts)

  • WRITE_BACK_EMAIL: Update source system

  • PAUSE: Add workflow delays

  • SEND_REST_REQUEST: Make HTTP requests to external APIs

  • SEND_NOTIFICATION: Trigger alerts

  • RESET_PASSWORD: Reset existing user password

  • CREATE_ACCESS_REVIEW: Trigger access review campaigns

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

Active Directory Attribute	Source Attributes	Transformer Value
account_name	display_full_name	{display_full_name}
distinguished_name	first_name, last_name	CN={first_name} {last_name},OU=Minnetonka,OU=US,OU=Evergreen Staff,DC=evergreentrucks,DC=local
user_principal_name	username	{username}@evergreentrucks.com
email	username	{username}@evergreentrucks.com
display_name	display_full_name	{display_full_name}
given_name	first_name	{first_name}
sur_name	last_name	{last_name}
country_code	work_location	{work_location}
job_title	job_title	{job_title}
primary_group_dn	-	CN=Domain Users,CN=Users,DC=evergreentrucks,DC=local

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:

Active Directory Attribute	Source Attributes	Transformer Value
account_name	display_full_name	{display_full_name}
distinguished_name	first_name, last_name	CN={first_name} {last_name},OU=Evergreen Termination,OU=Evergreen Staff,DC=evergreentrucks,DC=local
primary_group_dn	-	CN=Terminated Users,OU=Evergreen Groups,DC=evergreentrucks,DC=local

• 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

Action Hierarchy Requirement: The Sync Identities action is the only action type that can be declared at the root condition level. All other actions must be defined within sub-conditions after establishing a root condition with Sync Identities. The UI enforces this hierarchy.

Quick Reference

Action	Use When You Need To...
Sync Identities	Create or update user accounts in target systems
Manage Relationships	Assign or remove group memberships, roles
Create Email	Generate email addresses via email providers
Deprovision Identity	Disable accounts while preserving audit trails
Delete Identity	Permanently remove accounts (databases, cleanup)
Custom Action	Execute ServiceNow-specific operations
Write Back Email	Update HRIS with newly created email addresses
Pause	Add delays between workflow actions
Send REST Request	Make HTTP requests to external APIs
Send Notification	Trigger emails or webhooks on action events
Reset Password	Reset user passwords in target systems
Create Access Review	Automatically create certification campaigns

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

Setting	Description
Entity Type	The data source and type of identity to sync (e.g., Okta User, Azure AD User)
Create Allowed	Whether new identities can be created if not found
Attribute Sync	Keep attributes in sync even after initial creation
Common Synced Attributes	Shared transformation rules across multiple sync actions
Action Synced Attributes	Create, format, and modify the specified target attributes. See Transformers for more details

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

• Dynamically assign access based on user attributes (department, location, role)

Setting	Description
Access Profiles	Static Access Profiles to assign to the identity. See Access Profiles for more details about managing birthright entitlements
Dynamic Access Profiles	Attribute transformer expressions that resolve to Access Profile names at runtime based on user attributes. See Dynamic Access Profiles for details
Remove Existing Relationships	Whether to remove current relationships created during other Lifecycle Management actions before adding new ones

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

Setting	Description
Entity Type	The type of identity to create an email
Action Synced Attributes	Define how email attributes should be formatted. See Transformers for more details
Sync Action Name	Reference to sync action for conflict resolution

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

Setting	Description
Entity Type	The data source and target entity type to disable, delete, or lock
Remove All Relationships	Whether to remove existing group memberships and role assignments
Relationships to Create	Access Profile to apply after deprovisioning (e.g., move to specific groups)
Common Synced Attributes	Shared transformation rules across multiple deprovisioning actions
Action Synced Attributes	Target attributes to create, format, and modify for de-provisioned entities

Delete Identity

Permanently removes user accounts from target systems. Unlike the DEPROVISION_IDENTITY action which disables or suspends accounts while preserving audit records, DELETE_IDENTITY performs complete account removal.

Warning: DELETE_IDENTITY permanently removes accounts from target systems. Deleted data is typically unrecoverable. Consider using DEPROVISION_IDENTITY instead if you need to preserve audit trails or may need to reactivate accounts in the future.

Example Use Cases:

• Database user cleanup after employee offboarding

• Compliance with data deletion policies (e.g., GDPR right to be forgotten)

• Removing test or temporary accounts

• Service account lifecycle management

• Contractor account removal after project completion

Setting	Description
Entity Type	The data source and target entity type to permanently delete
Unique Identifiers	Attributes used to locate the user account for deletion (e.g., username, email, or account ID)
Attribute Transformers	Define how to identify and match the user for deletion. See Transformers for more details
Common Synced Attributes	Shared transformation rules across multiple delete actions
Sync Action Names	Reference to previous Sync Identities actions for unique identifier resolution

Supported Integrations:

• Active Directory (Users and Managed Service Accounts)

• Okta

• PostgreSQL

• MySQL

• OracleDB

• GitHub

• AWS RDS (MySQL, PostgreSQL, OracleDB)

• Custom Application

Custom Action

Executes integration-specific operations that extend beyond standard Lifecycle Management action types. CUSTOM_ACTION enables integrations to define specialized operations with flexible attribute schemas tailored to their unique capabilities.

CUSTOM_ACTION currently supports ServiceNow only. For generic HTTP requests to external APIs, use the Send REST Request action instead.

Example Use Cases:

• Insert records into ServiceNow tables when employees join or change roles

• Create ServiceNow incidents or requests as part of onboarding workflows

• Update ServiceNow CMDB records during employee lifecycle events

• Log audit records for compliance tracking

Setting	Description
Entity Type	The target integration and entity type to operate on
Table	(ServiceNow) The table name to insert records into (e.g., incident, sc_request, u_custom_table)
Attribute Transformers	Map source attributes to target table fields. See Transformers for more details

Custom Actions are non-idempotent. Each execution creates a new record. Running the same action multiple times will create duplicate records.

Supported Integrations:

Integration	Custom Action Capability	Documentation
ServiceNow	Insert records into any ServiceNow table	ServiceNow LCM

For detailed configuration examples including incident creation and audit logging, see ServiceNow Lifecycle Management.

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

Setting	Description
Entity Type	The type of entity to update with email information

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

Setting	Description
Duration in seconds	Number of seconds to pause the workflow

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.

Early Access: This feature is in Early Access and may require Veza support to enable. Contact your Customer Success Manager for availability.

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

• Execute webhooks to coordinate multi-system workflows

• Extract response data (like user IDs) from external systems for use in downstream actions

Setting	Description
Webhook URL	Target REST endpoint URL. Supports variable substitution using {attribute_name} syntax in URL path and query parameters
HTTP Method	Request method: GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS. Methods are case-insensitive and automatically converted to uppercase. POST, PUT, and PATCH require a JSON payload
Authorization Header	Required authentication header (e.g., Bearer <token>, X-API-Key: <key>, or custom authorization format)
JSON Payload	Request body in JSON format. Supports transformer syntax for attribute substitution: {"user": "{name}", "email": "{email}"}
Timeout	Maximum wait time in seconds for the request to complete (default: 60 seconds)
Only Send if Any Upstream Changes	When enabled, the request is only executed if a previous action in the workflow modified or created resources
Add Response to Output Entities	Extract entity data from the API response to make available for downstream actions
Output Entity Type	Type of entity to create from response (required if "Add Response to Output Entities" is enabled)
Response Entity Attribute	JSON path to extract from response using dot notation (e.g., result extracts response.result, data.user extracts response.data.user)
Response ID Attribute	Attribute name containing the entity identifier in the response (defaults to id)
Response Name Attribute	Attribute name containing the entity display name in the response (defaults to name)
Execute from Insight Point	Optional datasource ID to execute the request from an Insight Point instead of the control plane (useful for internal network-only APIs)

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:

URL: https://api.example.com/users/{email}/provision?dept={department}
Payload: {"name": "{first_name} {last_name}", "role": "{job_title | UPPER}"}

Available transformations include UPPER, LOWER, TRIM, and accessing nested attributes with dot notation, such as {Manager.email}. See Transformers 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:

{
  "result": {
    "user_id": "12345",
    "display_name": "John Doe"
  }
}

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

• PATCH: Partially update resources; requires JSON payload; sets AnyChanges flag

• DELETE: Remove resources; payload optional; sets AnyChanges flag

• HEAD: Metadata query without response body; payload optional; sets AnyChanges flag

• OPTIONS: Describes communication options for the target resource; payload optional; 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

• POST, PUT, and PATCH methods require non-empty, valid JSON payloads

Example: Suspend Okta users via REST API

The Send REST Request action can call Okta lifecycle APIs to suspend users, enabling workflows that handle leave of absence (LOA) scenarios before native Suspend action support is available.

Configuration:

Setting	Value
Webhook URL	https://{your-okta-domain}/api/v1/users/{employee_id | FROM_ENTITY_ATTRIBUTE,"OktaUser","employee_id","login"}/lifecycle/suspend
HTTP Method	POST
Authorization Header	SSWS {your-okta-api-token}
JSON Payload	{}

Key notes:

• User identification: Okta's suspend API requires the user's Okta ID or login. Use the FROM_ENTITY_ATTRIBUTE transformer to look up the Okta login from the Authorization Graph based on a source attribute like employee_id.

• Authorization format: Okta API tokens must be prefixed with SSWS (e.g., SSWS 00abcd1234...), not Bearer.

• Empty payload: The suspend endpoint requires a POST with an empty JSON object {} as the payload.

Example workflow condition:

To suspend users when their SOI lifecycle status changes to a leave state:

lifecycle_status eq "Leave" or lifecycle_status eq "Parental Leave" or lifecycle_status eq "Garden Leave"

Unsuspending users: To reactivate suspended users, create a separate workflow condition with the unsuspend endpoint:

https://{your-okta-domain}/api/v1/users/{employee_id | FROM_ENTITY_ATTRIBUTE,"OktaUser","employee_id","login"}/lifecycle/unsuspend

This approach is used when the SOI lifecycle status changes back to an active state (e.g., lifecycle_status eq "Employed").

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

Setting	Description
Notification Type	Select Email, Webhook, or Service Now
Email Template	(Email notifications only) Select the template to use for the notification. Choose "Default template" to use the event-specific template, or select a custom email template. See Custom Email Templates for details
Recipients	(Email notifications only) Specify email addresses to receive the notification, or select user attributes containing email addresses
Notification Settings	(Action notification settings) Configure email alerts on action success and/or failure for the specified recipients
Webhook Configuration	Configure webhooks to trigger on success and/or failure by specifying the URL to send the payload and optional auth header for the POST request
Veza Action	Select an existing Veza Action for pre-configured webhook or email settings

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 Notification Templates 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

Setting	Description
Entity Type	The target integration and entity type (e.g., AD User, Okta User)

Password complexity requirements, unique identifier options, and force-change-on-login settings vary by integration. See the integration-specific guides below for configuration details.

Supported Integrations:

• Active Directory

• Azure AD

• Okta

Create Access Review

Automatically creates access review campaigns during lifecycle events. This action bridges Lifecycle Management with Veza Access Reviews, enabling automated certification workflows triggered by identity lifecycle changes.

CREATE_ACCESS_REVIEW is a control-plane action that executes within the Veza platform. The action creates review campaigns asynchronously: first queuing the review, then creating it based on the defined certification plan.

Example Use Cases:

• Review contractor access 30 days after onboarding to ensure appropriate permissions

• Certify elevated permissions after role changes or promotions

• Trigger periodic access reviews based on employment anniversaries

• Automatically review access for high-risk roles or sensitive systems

• Create access reviews when users join specific departments or teams

Setting	Description
Certification Creation Plan	Defines the review scope, certification criteria, and reviewer assignment. See configuration details below

Certification Creation Plan Configuration:

The Certification Creation Plan is the core configuration element for CREATE_ACCESS_REVIEW:

Parameter	Required	Description
Access Workflow	Yes	The Access Workflow ID where the certification is created
Name	No	Name of the certification. Supports attribute transformers (e.g., Review for {name}). Custom names appear in Dry Run results
Data Source	Yes	Specifies which data to use: Current Data, Most Recent Snapshot, or a specific snapshot
Reviewer Assignment	No	Primary level reviewer assignment (manager, resource owners, or designated reviewers)
Fallback Reviewers	No	Reviewers to assign if automatic assignment fails
Due Date Offset	No	Time from certification start when reviews are due
Creation Mode	No	Create and Publish (starts immediately) or Create Draft (requires manual publishing)

Early Access: Multi-level approval (second and third level reviewers) is in Early Access and may require Veza support to enable.

How It Works:

1. A lifecycle event triggers a workflow containing the CREATE_ACCESS_REVIEW action

2. The action evaluates the Certification Creation Plan against the identity that triggered the event

3. A review campaign is queued in Veza Access Reviews

4. The review campaign is created and assigned to the designated reviewers

5. Reviewers receive notifications to certify or revoke the identified access

Event Notifications:

CREATE_ACCESS_REVIEW generates two notification events:

Event	Timing	Description
CREATE_ACCESS_REVIEW_QUEUED	Immediate	Sent when the review creation is queued
CREATE_ACCESS_REVIEW	Asynchronous	Sent when the review campaign is created

You can configure email notifications or webhooks for both events to track review creation progress. See Notification Templates for configuration details.

LCM-triggered reviews have special behaviors including automatic exclusion of unchanged results and entity type matching requirements. See Access Reviews from Lifecycle Management for complete behavior documentation.

Related Topics:

• Access Reviews from Lifecycle Management: Behavior, filtering, entity matching, and troubleshooting

• Access Reviews documentation: Configuring certification plans and managing reviews

• Access Profiles: Managing birthright entitlements included in reviews