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
WRITE_BACK_EMAIL: Update source system
PAUSE: Add workflow delays
SEND_NOTIFICATION: Trigger alerts
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 when provisioning AD Users. 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 |
|
distinguished_name | first_name, last_name |
|
user_principal_name | username |
|
username |
| |
display_name | display_full_name |
|
given_name | first_name |
|
sur_name | last_name |
|
country_code | work_location |
|
job_title | job_title |
|
primary_group_dn | - |
|
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 |
|
distinguished_name | first_name, last_name |
|
primary_group_dn | - |
|
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 authorizationUpdating 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
Administrators can choose and configure a range of actions when adding conditions to a workflow. Available actions depend on the configured integrations and target entity.
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 |
Continuous Sync | Keep attributes in sync even after initial creation |
Common Synced Attributes | Shared transformation rules across multiple sync actions |
Action Synced Attributes |
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
Setting | Description |
---|---|
Access Profiles | |
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 email for |
Action Synced Attributes | |
Sync Action Name | Reference to sync action for conflict resolution |
De-provision 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 de-provisioning (e.g., move to specific groups) |
Common Synced Attributes | Shared transformation rules across multiple de-provisioning actions |
Action Synced Attributes | Target attributes to create, format, and modify for de-provisioned entities |
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 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
Setting | Description |
---|---|
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 |
Last updated