> 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/access-agents/agents/lcm-policy-agent.md).

# LCM Policy Agent

Use the LCM Policy Agent in the workflow editor to draft and explain Lifecycle Management triggers, conditions, and attribute formatters, test them against your policy's identities, and answer questio

{% hint style="warning" %}
**AI-generated content:** The LCM Policy Agent uses generative AI to draft condition strings and attribute formatters from your description. Its suggestions can be inaccurate or incomplete. Review each suggestion and its explanation before applying it, and validate the policy with a dry run before publishing it.
{% endhint %}

Lifecycle Management triggers, conditions, and formatters have their own syntax, and a small mistake can match the wrong identities or produce the wrong account name. The LCM Policy Agent helps write them. Describe what you want in plain language, and the agent drafts the expression with an explanation. You decide whether to apply it to the workflow.

To explain failed runs or summarize a policy's runs, use the [LCM Run Analyst](/4yItIzMvkpAvMVFAamTf/features/access-agents/agents/lcm-run-analyst.md) instead.

## Capabilities

The agent can draft a new condition or formatter from a description, explain an existing one in plain language, or suggest an improvement to it. It can also test a condition or formatter against the policy's identities and describe what the policy contains. A condition can use the policy's own attributes, attributes from additional identity sources, system attributes that mark joiners, movers, and changed properties, and values mapped through the policy's lookup tables.

Some requests the agent can handle:

> "Build a condition for employees in Engineering whose manager is set and start date is in the next 30 days."
>
> "Explain what this formatter does."
>
> "Share suggestions for enhancements to this condition."
>
> "Who matches this condition?"
>
> "Does this policy have any lookup tables?"

If a request is ambiguous, such as "help me with this policy", the agent asks a clarifying question.

### Build triggers and conditions

A condition string is either a workflow's trigger condition, which defines the identities the workflow runs for, or a condition inside a workflow that decides which of its actions run. The agent writes it from the attributes available on the policy. For time-based conditions, it prefers [`WHEN()` relative date conditions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md#relative-date-conditions-with-when). `WHEN()` counts in days, so for month or year calculations the agent uses transformers instead.

The suggestion arrives on a card titled **Condition String**, with an explanation. For the request "Build a condition for employees in Engineering whose manager is set and start date is in the next 30 days", the suggestion is similar to:

```
department eq "Engineering" and manager ne "" and WHEN(hire_date within next 30 days)
```

| Action              | Effect                                                                                                                                                                          |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Apply Condition** | Writes the suggested condition string into the condition field in the workflow editor. No confirmation follows. The button is unavailable until a condition field is on screen. |
| **Reject**          | Declines the suggestion. The agent then asks what to change.                                                                                                                    |

When the Access AI panel is open outside the workflow editor, the card shows **Go to Workflow** instead of **Apply Condition**. It opens the workflow, and it is unavailable without policy and workflow context.

The agent does not warn when a condition matches more identities than you intended. To determine which identities a condition matches, ask the agent to [test it](#test-a-condition-or-formatter), or run a dry run.

### Build attribute formatters

A formatter generates the value of a destination attribute when an action that maps attributes runs, such as **Provision Account** (named **Sync Identities** in earlier releases) or **Deprovision Account**. The agent writes formatters for the attribute it was opened from and follows the destination's conventions: lowercase for emails, truncated for `sAMAccountName`, and capitalized for display names. A formatter can pass a value through (`{first_name}`), transform it (`{email | LOWER}`), branch with `IF / ELSE IF / ELSE` and SCIM filters, build composites with `APPEND` and `PREPEND`, and use lookup tables.

> "Build an email formatter for the AD destination from given name and surname, lowercase, falling back to employee ID."
>
> "Now also do one for first\_name."

The suggestion arrives on a card titled **Formatter for** followed by the destination attribute name, with an explanation. When the agent also suggests pipeline functions, the card lists them on a **Then apply:** line. A follow-up such as the second request keeps the policy and entity context and sends the next suggestion to the right attribute row.

| Action              | Effect                                                                                                                                                                                                   |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Apply Formatter** | Writes the suggested formatter, and any pipeline functions on the **Then apply:** line, into the matching attribute row. No confirmation follows. The button is unavailable until that row is on screen. |
| **Reject**          | Declines the suggestion. The agent then asks what to change.                                                                                                                                             |

The agent does not write nested `IF` expressions. When the destination attribute identifies the account, such as the action's unique identifier, it does not suggest `NEXT_NUMBER` or another transformer that returns several values. If you ask for one, it explains why and offers a deterministic alternative.

If the suggestion names no destination attribute, the card is titled **Formatter**, and **Apply Formatter** stays unavailable. In that case, open the agent with **Create with AI** on the attribute row.

### Test a condition or formatter

On request, the agent tests a condition string or a formatter against the identities of the open policy. It can test a suggestion before you apply it. When draft mode is on and the policy has a draft, the test uses the draft. Otherwise, it uses the published version.

> "Who matches this condition?"
>
> "Does this condition match Jane Doe?"
>
> "Try this formatter on a few identities."

* **Who a condition matches.** The agent lists up to 10 matching identities, or up to 25 if you ask, and links to the full list on the **Identities** page.
* **Whether a condition matches specific identities.** For up to 5 named identities, the agent reports whether each one matched. For an identity that did not match, it names the comparison that failed, with the expected and actual values.
* **What a formatter produces.** For up to 5 named identities, or the first 3 identities of the policy if none are named, the agent shows the formatted value and the attribute values it read.

The agent tests only when you ask. It does not test a condition on a credential attribute, such as a password or a token, and in formatter results, credential values appear as `<redacted>`. When a formatter reads a `$` alias, the test does not apply the policy's alias definitions, so the result for that part can differ from a real run. The agent says when this applies.

A test is not a dry run. Before publishing the policy, validate it with a [dry run](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/test-policies-with-dry-run.md).

### Inspect a policy

Ask what a policy contains, such as its workflows, actions, conditions, and lookup tables, and the agent summarizes it in the Access AI panel.

The agent does not answer questions about runs. With **Auto** selected, the panel sends those to the [LCM Run Analyst](/4yItIzMvkpAvMVFAamTf/features/access-agents/agents/lcm-run-analyst.md). A thread that **Create with AI** or one of its suggested actions starts stays with the LCM Policy Agent.

## How suggestions reach the workflow

Every condition or formatter arrives as a suggestion card that you apply or reject. Applying a suggestion changes the form only. Nothing is saved until you save the workflow.

The agent reads the policy's attributes, available transformers, workflows, actions, conditions, and lookup tables to write a suggestion. When draft mode is on and the policy has a draft, the agent reads the draft. Otherwise, it reads the published version. Before it suggests a condition, it checks the syntax with Veza's condition validator. That check is structural: it does not compare attribute names with the policy, and formatters are not validated. The agent does not read run data or run workflows.

## Where it appears in the product

* **Workflow editor**: **Create with AI** next to a condition string or a formatter opens the agent with that field in context. When the field has a value, the Access AI panel offers suggested actions. For the fields that offer the button, see [Create with AI for Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/create-with-ai.md).
  * For a condition: **Show identities that match this trigger**, **Test this condition against identities**, **Share suggestions for enhancements**, and **Change or add to this trigger**.
  * For a formatter: **Try this formatter on a few identities**, **Test this formatter on a specific identity**, **Explain what this formatter does**, **Share suggestions for enhancements**, and **Change or add to this formatter**.
* **Shared Attribute Mapping attribute row**: **Create with AI** on an attribute row of a shared attribute mapping (a **Transformer** in earlier releases) opens the agent with the same destination context as an action's attribute row, and returns a formatter suggestion, not a condition string.
* **Workflow editor**: **Toggle Access AI Panel** in the editor header opens the Access AI panel without a field in context.
* **Any page**: **Toggle Access AI Panel** in the top navigation bar opens the Access AI panel. Keep **Auto** or select **LCM Policy Agent** in the agent selector. Outside a policy, the agent asks for the policy ID.

When **Create with AI** opens the agent on an empty field, the agent starts drafting a value.

## Who can use the LCM Policy Agent

* **Availability and setup:** See [Enabling Access AI](/4yItIzMvkpAvMVFAamTf/features/access-agents.md#enabling-access-ai).
* **Opening the agent:** Any built-in role that includes Access AI can select the agent in the agent selector. **Create with AI** appears only where a condition or formatter is edited: the workflow editor and a shared attribute mapping's edit panel. Both require the Administrator [role](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md).
* **What it reads:** The open policy and the open condition field, and for a test the policy's identities, with your permissions. Only the Administrator, Operator, and Viewer roles can read Provisioning Policies, so for other roles a request stops before it completes.
* **Completing actions:** **Apply Condition** works only in the workflow editor. **Apply Formatter** works only while the matching attribute row is on screen, in the workflow editor or a shared attribute mapping's edit panel.
* **Other roles:** Only the Administrator role can open either one. For other roles, **Apply Formatter** stays disabled, and a condition card shows **Go to Workflow** instead. See [Create with AI for Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/create-with-ai.md#before-you-start).

## Related

* [Veza Access Agents](/4yItIzMvkpAvMVFAamTf/features/access-agents.md)
* [Access Agents](/4yItIzMvkpAvMVFAamTf/features/access-agents/agents.md)
* [LCM Run Analyst](/4yItIzMvkpAvMVFAamTf/features/access-agents/agents/lcm-run-analyst.md)
* [Create with AI for Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/create-with-ai.md)
* [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management.md)
* [Provisioning Policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md)
* [Provision Account action](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md)
* [Trigger Conditions Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/trigger-conditions-reference.md)
* [Transformer Reference](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/transformer-reference.md)
* [Test policies with dry run](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/test-policies-with-dry-run.md)


---

# 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/access-agents/agents/lcm-policy-agent.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.