> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md).

# Trigger Conditions Reference

Complete reference for SCIM filter syntax used in Lifecycle Management workflow trigger conditions

This page provides a comprehensive reference for the SCIM filter syntax used in Lifecycle Management workflow trigger conditions. Trigger conditions determine **when** a workflow action should execute based on identity attributes.

## SCIM Filter Syntax Overview

SCIM (System for Cross-domain Identity Management) filter syntax provides a standardized way to express conditions. The basic structure is:

```txt
<attribute> <operator> <value>
```

For example:

```txt
department eq "Engineering"
```

This condition evaluates to `true` when the identity's `department` attribute equals "Engineering".

## Comparison Operators

The `pr` (present) operator does not evaluate as expected in LCM conditions. To test that an attribute has a value, use `attribute ne ""`.

### String Operators

| Operator | Name        | Description                  | Example                   |
| -------- | ----------- | ---------------------------- | ------------------------- |
| `eq`     | Equal       | Exact match (case-sensitive) | `department eq "Sales"`   |
| `ne`     | Not Equal   | Does not match               | `status ne "Terminated"`  |
| `co`     | Contains    | Substring match              | `email co "@company.com"` |
| `sw`     | Starts With | Prefix match                 | `employee_id sw "EMP"`    |
| `ew`     | Ends With   | Suffix match                 | `email ew "@company.com"` |

### Numeric Operators

| Operator | Name                  | Description              | Example                  |
| -------- | --------------------- | ------------------------ | ------------------------ |
| `eq`     | Equal                 | Exact numeric match      | `department_code eq 100` |
| `ne`     | Not Equal             | Does not equal           | `level ne 0`             |
| `lt`     | Less Than             | Strictly less than       | `access_level lt 5`      |
| `le`     | Less Than or Equal    | Less than or equal to    | `risk_score le 50`       |
| `gt`     | Greater Than          | Strictly greater than    | `tenure_months gt 12`    |
| `ge`     | Greater Than or Equal | Greater than or equal to | `salary_grade ge 3`      |

### Boolean Operators

| Operator | Name      | Description     | Example                 |
| -------- | --------- | --------------- | ----------------------- |
| `eq`     | Equal     | Boolean match   | `is_active eq true`     |
| `ne`     | Not Equal | Boolean inverse | `is_contractor ne true` |

### Timestamp Operators

Timestamp comparisons use ISO 8601 format (`YYYY-MM-DDTHH:MM:SSZ`).

| Operator | Name         | Description           | Example                                      |
| -------- | ------------ | --------------------- | -------------------------------------------- |
| `eq`     | Equal        | Exact timestamp match | `hire_date eq "2024-01-15T00:00:00Z"`        |
| `lt`     | Before       | Earlier than          | `termination_date lt "2024-06-01T00:00:00Z"` |
| `le`     | At or Before | At or earlier than    | `start_date le "2024-12-31T23:59:59Z"`       |
| `gt`     | After        | Later than            | `hire_date gt "2023-01-01T00:00:00Z"`        |
| `ge`     | At or After  | At or later than      | `last_login ge "2024-01-01T00:00:00Z"`       |

### String List Operators

For attributes that contain multiple values (arrays), the following operators are supported:

| Operator | Name      | Description                    | Example                         |
| -------- | --------- | ------------------------------ | ------------------------------- |
| `co`     | Contains  | List contains a specific value | `employee_types co "Full Time"` |
| `eq`     | Equal     | List exactly matches value(s)  | `roles eq "Admin"`              |
| `ne`     | Not Equal | List does not match value(s)   | `tags ne "deprecated"`          |

{% hint style="info" %}
The `co` operator is most commonly used for checking membership in a list. Use `eq` for exact list matching and `ne ""` to verify the attribute has a value.
{% endhint %}

## Case sensitivity

String operators compare attribute **values** case-sensitively. For example, `department eq "Sales"` matches `Sales` but not `sales` or `SALES`. This applies to every string operator, including `ne`, `co`, `sw`, and `ew`.

To compare values regardless of case, normalize both sides with a transformer such as `LOWER` or `UPPER`. See [Dynamic Value Comparisons with Embedded Transformers](#dynamic-value-comparisons-with-embedded-transformers).

Write attribute names in lowercase (for example, `department`, not `Department`). Source attribute names are stored in lowercase, and [system attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/system-attributes.md) such as `sys_attr__is_mover` must be written in their exact lowercase form.

{% hint style="info" %}
This differs from the SCIM standard, which compares string values case-insensitively unless the attribute is defined as `caseExact`. Lifecycle Management always compares string values case-sensitively.
{% endhint %}

## Logical Operators

Combine multiple conditions using logical operators.

| Operator | Description                   | Example                                             |
| -------- | ----------------------------- | --------------------------------------------------- |
| `and`    | Both conditions must be true  | `is_active eq true and department eq "IT"`          |
| `or`     | Either condition must be true | `department eq "IT" or department eq "Engineering"` |
| `not`    | Negates a condition           | `not(status eq "Terminated")`                       |

{% hint style="info" %}
The `not()` operator takes a condition in parentheses and can negate a group, such as `not(department eq "IT" or department eq "Engineering")`. To negate a single comparison, `ne` is shorter: `status ne "Terminated"`.
{% endhint %}

### Precedence

* `not` has the highest precedence
* `and` has higher precedence than `or`
* Use parentheses `()` to control evaluation order

**Example combining operators:**

```txt
# Full-time employees in Engineering or IT departments
employee_types co "Full Time" and (department eq "Engineering" or department eq "IT")
```

## Common Trigger Condition Patterns

### Joiner Scenarios

```txt
# New full-time employees in specific departments
employee_types co "Full Time" and (department eq "Engineering" or department eq "Sales")

# New hires with specific job levels
is_active eq true and job_level ge 3 and hire_date gt "2024-01-01T00:00:00Z"

# Contractors starting in a specific region
is_contractor eq true and location sw "US-"
```

### Mover Scenarios

Two system attributes support mover detection:

* **`sys_attr__is_mover`**: Set to `true` when any property in the policy's **Mover Properties** list changes. Indicates that the identity changed, but does not identify which property changed.
* **`sys_attr_changed__<property>`**: Set to `true` for each specific property that changed in the most recent extraction. These attributes are transient and are cleared at the start of each extraction cycle.

Use `sys_attr__is_mover` when you want to trigger on any mover event. Use `sys_attr_changed__<property>` when you need to trigger only on specific property changes or combinations.

**Broad mover detection with `sys_attr__is_mover`**:

```txt
# Any change in monitored properties for active employees
sys_attr__is_mover eq true and is_active eq true

# Department-specific mover handling (identity moved AND is now in Engineering)
sys_attr__is_mover eq true and department eq "Engineering"

# Mover detection combined with employment type
sys_attr__is_mover eq true and is_active eq true and employee_types co "Full Time"
```

**Targeted mover detection with `sys_attr_changed__`**:

```txt
# Triggers only when department changes TO Sales (not when Sales employees change other attributes)
department_name eq "Sales" and sys_attr_changed__department_name eq true

# Triggers when manager changes for active employees in specific departments
sys_attr_changed__managers eq true and employment_status eq "ACTIVE" and (department_name eq "Engineering" or department_name eq "Marketing" or department_name eq "Sales")

# Triggers when any of several properties change
(sys_attr_changed__department_name eq true or sys_attr_changed__job_title eq true or sys_attr_changed__managers eq true) and employment_status eq "ACTIVE"

# Triggers only when BOTH a location field AND manager change in the same extraction
(sys_attr_changed__customprop_management_chain_level_03 eq true or sys_attr_changed__customprop_management_chain_level_04 eq true) and sys_attr_changed__managers eq true
```

See [System Attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/system-attributes.md#sys_attr_changed__property) for the full `sys_attr_changed__` reference.

### Leaver Scenarios

```txt
# Terminated employees
employment_status eq "Terminated"

# Inactive contractors
is_active eq false and is_contractor eq true

# Users with imminent termination date
termination_date le "2024-12-31T23:59:59Z" and termination_date gt "2024-01-01T00:00:00Z"
```

### Attribute-Based Access Control

```txt
# High-privilege access for senior engineers
department eq "Engineering" and job_level ge 5 and is_active eq true

# Region-specific access
location sw "EMEA-" and employee_types co "Full Time"

# Cost center based provisioning
cost_center eq "CC-1000" and is_active eq true
```

## System Attributes in Conditions

Lifecycle Management provides two families of computed system attributes for use in trigger conditions:

* **`sys_attr__` prefix**: Persistent boolean flags such as `sys_attr__is_mover` (any monitored property changed) and `sys_attr__is_new_identity` (first appearance of an identity).
* **`sys_attr_changed__` prefix**: Per-property change detection attributes, transient per extraction cycle. `sys_attr_changed__department eq true` means department changed in the most recent extraction.

See [System Attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/system-attributes.md) for the complete reference.

## Dynamic Value Comparisons with Embedded Transformers

For time-sensitive workflows, you can embed transformer functions directly in condition values. This enables comparisons against dynamically-computed dates and times rather than static values.

### Syntax

Embedded transformers use the `{| FUNCTION | ...}` syntax. The pipe (`|`) immediately after the opening brace indicates there is no source attribute—the expression starts directly with a function:

```txt
{| NOW | UTC_TO_TIME_ZONE, "-05:00" | DATE_FORMAT, "DateOnly"}
```

This differs from attribute transformers where you reference an attribute first:

* **Attribute transformer:** `{hire_date | DATE_FORMAT, "DateOnly"}` (starts with attribute)
* **Embedded in condition:** `{| NOW | DATE_FORMAT, "DateOnly"}` (starts with function)

### Common Functions for Dynamic Conditions

| Function           | Purpose                      | Example |
| ------------------ | ---------------------------- | ------- |
| `NOW`              | Current UTC timestamp        | \`{     |
| `UTC_TO_TIME_ZONE` | Convert to specific timezone | \`{     |
| `DATE_ADJUST_DAY`  | Add/subtract days            | \`{     |
| `DATE_FORMAT`      | Format for comparison        | \`{     |

See [Transformer Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/transformer-reference.md) for all available functions.

### Example: 2-Day Leaver Window

Trigger a leaver workflow when an employee's last day of work falls within a 2-day window around today (Eastern Standard Time):

```txt
is_active eq true
and customprop_lastdayofwork le "{| NOW | UTC_TO_TIME_ZONE, \"-05:00\" | DATE_ADJUST_DAY, 0 | DATE_FORMAT, \"DateOnly\"}"
and customprop_lastdayofwork gt "{| NOW | UTC_TO_TIME_ZONE, \"-05:00\" | DATE_ADJUST_DAY, -2 | DATE_FORMAT, \"DateOnly\"}"
```

**Breaking down the embedded transformer:**

| Step | Function                     | Input              | Output                         |
| ---- | ---------------------------- | ------------------ | ------------------------------ |
| 1    | `NOW`                        | (none)             | Current UTC timestamp          |
| 2    | `UTC_TO_TIME_ZONE, "-05:00"` | UTC timestamp      | Eastern time timestamp         |
| 3    | `DATE_ADJUST_DAY, 0`         | EST timestamp      | Today (or `-2` for 2 days ago) |
| 4    | `DATE_FORMAT, "DateOnly"`    | Adjusted timestamp | Date string for comparison     |

**Result:** The workflow triggers when:

* The employee is active (`is_active eq true`)
* Their last day is today or earlier (`le` today)
* Their last day is after 2 days ago (`gt` 2 days ago)

This creates a 2-day processing window for departing employees.

### Example: Pre-Hire Provisioning

Trigger a joiner workflow 7 days before an employee's start date:

```txt
is_active eq false
and hire_date le "{| NOW | DATE_ADJUST_DAY, 7 | DATE_FORMAT, \"DateOnly\"}"
and hire_date gt "{| NOW | DATE_FORMAT, \"DateOnly\"}"
```

This triggers for employees whose hire date is within the next 7 days, enabling pre-provisioning of accounts before their start date. For a Workday source of identity, see [Pre-hires](/4yItIzMvkpAvMVFAamTf/integrations/integrations/workday.md#pre-hires) for how Veza marks pre-hire Workers and the integration setting they require.

### Example: Post-Termination Cleanup

Trigger a cleanup workflow for employees terminated more than 30 days ago:

```txt
employment_status eq "Terminated"
and termination_date lt "{| NOW | DATE_ADJUST_DAY, -30 | DATE_FORMAT, \"DateOnly\"}"
```

{% hint style="warning" %}
**Escaping quotes:** When embedding transformers in conditions, you must escape inner quotes with backslashes. For example: `\"-05:00\"` and `\"DateOnly\"`.
{% endhint %}

{% hint style="info" %}
**Timezone consideration:** Use `UTC_TO_TIME_ZONE` to ensure date comparisons align with your organization's business timezone. Without timezone conversion, comparisons use UTC which may cause workflows to trigger at unexpected times.
{% endhint %}

### Related Documentation

For a conceptual overview of how conditions and transformers work together, see [Understanding Conditions and Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/conditions-and-transformers-overview.md).

## Relative Date Conditions with WHEN()

**Available in Veza v2026.8.31 and later.**

A `WHEN()` expression compares a date attribute to the current date, a fixed date, or another date attribute. Veza converts each expression into the equivalent embedded-transformer comparison (see [Dynamic Value Comparisons with Embedded Transformers](#dynamic-value-comparisons-with-embedded-transformers)) every time it evaluates the condition, so you don't write the `NOW` and `DATE_ADJUST_DAY` pipeline yourself.

```txt
WHEN(<attribute> <pattern>)
```

* The attribute comes first and is required.
* `WHEN` and the pattern keywords are case-insensitive. `when(start_date within last 7 days)` and `WHEN(start_date WITHIN LAST 7 DAYS)` are equivalent.
* A `WHEN()` expression is a complete clause. Combine it with other clauses using `and`, `or`, and parentheses, for example `WHEN(start_date within next 7 days) and department eq "Sales"`.

You can use `WHEN()` in workflow trigger conditions (**Identity matches this condition**) and in **Condition String** conditions. Transformers and attribute formatters don't accept it.

### Supported patterns

In the table, `N` and `M` are day counts. A day count is a positive whole number or the name of an attribute that holds one. `DATE` is a date in `YYYY-MM-DD` format or the name of another date attribute.

| Pattern                         | Matches when the attribute is                                                                              | Example                                                   |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| `within last N days`            | In the last `N` days, up to and including today                                                            | `WHEN(start_date within last 7 days)`                     |
| `within next N days`            | In the next `N` days, starting today                                                                       | `WHEN(start_date within next 7 days)`                     |
| `between N and M days ago`      | Between `N` and `M` days in the past, excluding both boundary days. `N` must be less than `M`.             | `WHEN(termination_date between 30 and 90 days ago)`       |
| `between N and M days from now` | Between `N` and `M` days in the future, excluding both boundary days. `N` must be less than `M`.           | `WHEN(contract_end_date between 30 and 90 days from now)` |
| `before now`, `after now`       | Earlier or later than the current time. With the **Date Only** format, Veza compares against today's date. | `WHEN(termination_date before now)`                       |
| `before today`, `after today`   | Earlier or later than today's date                                                                         | `WHEN(start_date after today)`                            |
| `is today`                      | Today's date                                                                                               | `WHEN(start_date is today)`                               |
| `before DATE`, `after DATE`     | Earlier or later than `DATE`                                                                               | `WHEN(start_date before 2027-01-01)`                      |
| `is DATE`                       | The same as `DATE`                                                                                         | `WHEN(start_date is hire_date)`                           |
| `N days before <attribute>`     | Earlier than the date `N` days before the other attribute                                                  | `WHEN(start_date 5 days before hire_date)`                |
| `N days after <attribute>`      | Later than the date `N` days after the other attribute                                                     | `WHEN(start_date 30 days after hire_date)`                |

`WHEN()` counts only in days. Write `day` or `days` after the count. For a week, use `7 days`. For month and year spans, use a [`DATE_ADJUST`](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/transformer-reference.md#date_adjust) embedded transformer instead.

The condition editor rejects an expression that:

* Has no closing parenthesis, or has no attribute before the pattern
* Uses a day count of zero or less, or a `between` range where `N` isn't less than `M`
* Uses a date that isn't in `YYYY-MM-DD` format
* Uses `is now`. Use `before now` or `after now` instead.
* Adds words after the pattern, such as `as datetime` or `in America/New_York`. Set the format and time zone in the policy properties instead.

### Set the date format and time zone

Each attribute that begins a `WHEN()` expression needs an entry in **Properties for ‘When’ Expressions in Conditions**. The entry sets the format and time zone Veza uses to build the comparison dates for that attribute.

In **Select Format**, choose **Date Only** for attributes that store a calendar date, such as `2026-01-15`. Choose **Date and Time** for attributes that store a timestamp, such as `2026-01-15T08:00:00Z`.

The time zone decides when "today" begins and ends. Choose one time zone for every identity, or select **Based on Location (Lookup Table)** to read each identity's time zone from a policy lookup table. For a lookup, select the **Key Attribute** on the identity, the **Lookup Table**, the **Match on Column** that holds the key values, and the return column that holds an IANA time zone name (such as `America/New_York`) or a UTC offset (such as `-05:00`). An identity whose key value has no matching row uses UTC. An identity without the key attribute doesn't match the `WHEN()` expression.

To add an entry:

1. Open the policy's draft version and select the **Workflow Components** tab.
2. Select the **Properties** card.
3. Under **Properties for ‘When’ Expressions in Conditions**, click **Add**.
4. In **Select Source Attributes**, select one or more attributes. The list shows only date and time attributes, and an attribute can belong to only one entry.
5. Choose the format and the time zone, then click **Save**.

Changes to these entries take effect when you publish the policy version. You can't delete an entry while a `WHEN()` expression uses one of its attributes.

While you type a condition, the editor flags any `WHEN()` attribute that has no entry, and the condition isn't valid until you add one. Click **Add Properties** to create an entry, or **Apply Properties** to add the attributes to the most recently added entry with its format and time zone.

`is today`, `is DATE`, `before today`, and `after today` compare dates only, whatever the format. The time zone doesn't apply to `before DATE`, `after DATE`, and `is DATE`. A policy saved through the API without an entry for an attribute uses **Date Only** and UTC for that attribute.

### Identities without a date value

An identity that has no value for the attribute doesn't match the `within`, `between`, `after`, or `is` patterns. It **does** match the `before` patterns, because Veza treats a missing date as earlier than any date. To exclude those identities, add a non-empty check:

```txt
WHEN(termination_date before today) and termination_date ne ""
```

Veza compares attribute values in ISO 8601 form, such as `2026-01-15` or `2026-01-15T08:00:00Z`, as dates. It compares values in other formats, such as `01/15/2026`, as text, and those comparisons don't return reliable results.

Veza evaluates a `WHEN()` expression against the current time at each policy run, so an identity can start matching without any change to its attributes. With **Have changed** and **Specific properties** selected, a workflow doesn't run for a match caused only by the passage of time. See the [LCM FAQ](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/lcm-faq.md#policy-configuration).

### Examples

```txt
# Joiner: start date is today or in the next 7 days
WHEN(start_date within next 7 days) and employee_types co "Full Time"

# Leaver: termination date has passed
WHEN(termination_date before today) and termination_date ne ""

# Cleanup: terminated between 30 and 90 days ago
WHEN(termination_date between 30 and 90 days ago) and employment_status eq "Terminated"
```

{% hint style="info" %}
**Create with AI** writes time-based conditions as `WHEN()` expressions. For month and year spans, it writes a `DATE_ADJUST` expression instead. See [Create with AI for Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/create-with-ai.md).
{% endhint %}

### Example: Use each identity's local time zone

When identities work in different time zones, a single fixed time zone can start a workflow a day early or a day late for some of them. To evaluate "today" in each identity's own time zone, read the time zone from a lookup table keyed on an identity attribute, such as the office location.

1. Create a lookup table that maps each location to an IANA time zone name or a UTC offset, and add it to the policy's draft version. See [Create a Lookup Table](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md#create-a-lookup-table).

   | location  | time\_zone         |
   | --------- | ------------------ |
   | New York  | `America/New_York` |
   | London    | `Europe/London`    |
   | Singapore | `Asia/Singapore`   |
2. Add an entry for `start_date` under **Properties for ‘When’ Expressions in Conditions**, as described in [Set the date format and time zone](#set-the-date-format-and-time-zone). Select **Date Only** and **Based on Location (Lookup Table)**, then set:
   * **Key Attribute**: `location`
   * **Lookup Table**: the table from step 1
   * **Match on Column**: `location`
   * **Return Column for Timezone Value**: `time_zone`
3. Use the attribute in the workflow's trigger condition:

   ```txt
   WHEN(start_date is today)
   ```

Veza determines "today" separately for each identity, so a New York hire and a Singapore hire with the same start date each match on their own local date. The workflow runs at the first policy run that falls on that local date. If no policy run falls on that date, the identity doesn't match. To allow for a missed run, use `within last N days` instead. An identity whose location has no row in the table uses UTC, and an identity without a `location` value doesn't match.

Because the match comes from the date changing, not from a change to the identity's attributes, a workflow with **Have changed** and either **Specific properties** or **Used properties** selected doesn't run for it. See the [LCM FAQ](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/lcm-faq.md#policy-configuration).

## Best Practices

### Use Specific Conditions

```txt
# Good: Specific and targeted
department eq "Engineering" and job_level ge 3 and is_active eq true

# Avoid: Too broad, may affect unintended users
department eq "Engineering"
```

### Test with Dry Run

Before enabling a policy, use the **Dry Run** feature to preview which identities match your trigger conditions. This helps catch overly broad or restrictive conditions before they affect real accounts.

### Combine Conditions Thoughtfully

```txt
# Use parentheses for clarity when mixing and/or
(department eq "IT" or department eq "Engineering") and is_active eq true

# Without parentheses, this evaluates differently due to precedence:
# department eq "IT" or (department eq "Engineering" and is_active eq true)
department eq "IT" or department eq "Engineering" and is_active eq true
```

### Handle Edge Cases

Consider what happens when attributes are null or empty:

```txt
# Explicit check for non-empty department
department ne "" and department eq "Engineering"

# Check for active status before other conditions
is_active eq true and department eq "Engineering"
```

## Troubleshooting

### Condition Not Matching Expected Users

1. **Check value case**: String values are matched case-sensitively — `eq "Sales"` will not match `sales`. Normalize with `LOWER` or `UPPER` if needed (see [Case sensitivity](#case-sensitivity)).
2. **Check attribute names**: Ensure the attribute name matches the source attribute, using its lowercase form
3. **Verify data types**: String values need quotes, booleans don't
4. **Review operator choice**: `co` for contains vs. `eq` for exact match
5. **Use Dry Run**: Test the condition against specific identities

### Condition Matching Too Many Users

1. **Add specificity**: Combine multiple conditions with `and`
2. **Check for broad patterns**: `co ""` matches all non-null values
3. **Verify logical grouping**: Ensure `and`/`or` precedence is correct

### Timestamp Issues

1. **Use ISO 8601 format**: `YYYY-MM-DDTHH:MM:SSZ`
2. **Include timezone**: Always use `Z` suffix for UTC
3. **Check attribute type**: Ensure the source attribute is a timestamp, not a string

## Related Topics

* [Understanding Conditions and Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/conditions-and-transformers-overview.md) - Conceptual overview of conditions vs. transformers
* [Policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md) - Create and configure Lifecycle Management policies
* [Conditions and Actions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md) - Configure workflow actions and their triggers
* [Attribute Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.md) - Transform attribute values using formatter syntax
* [Transformer Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/transformer-reference.md) - Complete list of transformation functions
* [System Attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/system-attributes.md) - Available system attributes for conditions
* [Dynamic Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-access-profiles.md) - Formatter-based profile assignment
* [Attribute Mapping](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/attribute-mapping.md) - Map source attributes to target attributes


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

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

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.