# 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
* 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
* Can check for entities in the Access Graph ([NODE\_IN\_GRAPH](#node_in_graph-condition)) or in previous action output ([ENTITY\_TYPE\_IN\_OUTPUT](#entity_type_in_output-condition))

> **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
  * ROTATE\_KEY: Rotate cryptographic keys in Azure Key Vault
  * GET\_NODE\_FROM\_GRAPH: Query the Access Graph for entities by type and filter
  * CREATE\_ENTITLEMENT: Create roles, groups, or distribution lists in target systems

### Error Handling for Actions

By default, when an action fails during workflow execution, the workflow stops and no further actions in that condition are executed. Two options allow workflows to continue past action failures instead of stopping:

#### Continue if any action fails (Condition-level)

Enable **Continue Actions If Any Error** on a **condition** to keep the workflow running even if any action under that condition fails. This is a blanket setting — if any action fails, the workflow continues to the next action instead of stopping. It applies equally to every action in the condition.

**When to use:** When all actions in a condition are independent and none are prerequisites for others. For example, a condition with three notification actions (Slack, email, ServiceNow ticket) where each should fire regardless of the others.

#### Continue if this action fails (Action-level)

Enable **Continue Workflow on Error** on an individual **action** to keep the workflow running if that specific action fails. The workflow continues to the next step instead of stopping, while other actions in the condition remain critical.

**When to use:** When most actions in a condition are critical but one specific step is optional. For example, a condition with three actions (Revoke Access, Send Slack Notification, Update CMDB) where the Slack notification is nice-to-have but the other two must succeed.

{% hint style="info" %}
When either option is enabled, failed actions are still recorded as **Errored** in the [Activity Log](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/activity-log.md), but the overall workflow task completes successfully. This ensures errors remain visible and auditable even though they did not halt execution.
{% endhint %}

| Setting                                   | Scope                      | Effect                                                                            |
| ----------------------------------------- | -------------------------- | --------------------------------------------------------------------------------- |
| Continue Actions If Any Error (Condition) | All actions in a condition | If any action fails, the workflow continues instead of stopping                   |
| Continue Workflow on Error (Action)       | One specific action        | If this action fails, the workflow continues to the next step instead of stopping |

### 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

```mermaid
graph TD
    subgraph Provisioning
        A[[Workflow: Workday Worker - Active]] --> |Workday Worker| B([Sync User to AD])
        B --> |AD User| C([Create Exchange Email])
        C --> |User Email| D([Write Back Email to Workday])
        C --> |User Email| E([Sync Email to AD])
    end

    subgraph Entitlements
        E --> |AD User| F{Dept = Sales?}
        E --> |AD User| G{Dept = Eng?}
        F --> H([Assign Sales AD Group])
        G --> I([Assign Eng AD Group])
        G --> J([Assign Eng Snowflake Group])
    end
```

#### 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

{% hint style="warning" %}
**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.
{% endhint %}

### Quick Reference

| Action                                                                                                                         | Use When You Need To...                                        |
| ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------- |
| [Sync Identities](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md)           | Create or update user accounts in target systems               |
| [Manage Relationships](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/manage-relationships.md) | Assign or remove group memberships, roles                      |
| [Create Email](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/create-email.md)                 | Generate email addresses via email providers                   |
| [Deprovision Identity](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/deprovision-identity.md) | Disable accounts while preserving audit trails                 |
| [Delete Identity](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/delete-identity.md)           | Permanently remove accounts (databases, cleanup)               |
| [Custom Action](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/custom-action.md)               | Execute ServiceNow-specific operations                         |
| [Write Back Email](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/write-back-email.md)         | Update HRIS with newly created email addresses                 |
| [Pause](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/pause.md)                               | Add delays between workflow actions                            |
| [Send REST Request](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md)       | Make HTTP requests to external APIs                            |
| [Send Notification](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-notification.md)       | Trigger emails or webhooks on action events                    |
| [Reset Password](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/reset-password.md)             | Reset user passwords in target systems                         |
| [Create Access Review](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/create-access-review.md) | Automatically create certification campaigns                   |
| [Rotate Key](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/rotate-key.md)                     | Rotate Azure Key Vault keys (NHI feature)                      |
| [Get Node From Graph](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/get-node-from-graph.md)   | Look up entities in the Access Graph during workflow execution |
| [Create Entitlement](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/create-entitlement.md)     | Create groups, roles, or distribution lists in target systems  |

## Graph Condition Types

The following condition types enable workflow branching based on Access Graph data. They are designed to work with [Get Node From Graph](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/get-node-from-graph.md) actions.

### NODE\_IN\_GRAPH Condition

Checks whether entities matching an entity type and optional SCIM filter exist in the Access Graph. This is a **graph-level check** — it queries the Access Graph cache, independent of previous action results.

| Setting     | Description                                                                    |
| ----------- | ------------------------------------------------------------------------------ |
| Entity Type | **(Required)** The entity type to search for (e.g., `OktaUser`, `AwsIamRole`). |
| Filter      | **(Optional)** SCIM filter to narrow the check (e.g., `status eq "ACTIVE"`).   |

**When to use:** When the workflow should branch based on whether specific entities exist in the graph — for example, "only proceed if an active OktaUser matching this filter exists."

### ENTITY\_TYPE\_IN\_OUTPUT Condition

Checks whether any node of a specified entity type exists in the accumulated workflow output from previous [Get Node From Graph](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/get-node-from-graph.md) actions.

| Setting     | Description                                                                            |
| ----------- | -------------------------------------------------------------------------------------- |
| Entity Type | **(Required)** The entity type to check for in the workflow output (e.g., `JiraUser`). |

**When to use:** When the workflow should branch based on whether a previous graph lookup returned results of a specific type — for example, "if the previous action found JiraUser nodes, proceed with provisioning."

{% hint style="info" %}
Entity type matching uses [entity type groupings](/4yItIzMvkpAvMVFAamTf/features/search/entities/entity-type-groupings.md) when available. This means specifying a parent grouping (such as `User`) can match child types (such as `OktaUser` or `AzureADUser`).
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.