> 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-run-analyst.md). # LCM Run Analyst Explain a failed Lifecycle Management provisioning action, summarize a policy's runs over a period, and diagnose why a policy or workflow did not run. {% hint style="warning" %} **AI-generated content:** The LCM Run Analyst uses generative AI to explain failed provisioning actions, summarize policy runs, and explain why a policy did not run. Its answers can be inaccurate or incomplete. Treat an explanation as a starting point for your own diagnosis: confirm the cause against the raw error and the attribute values in the run detail, and validate any policy change with a [dry run](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/test-policies-with-dry-run.md) before you enable it. {% endhint %} When a provisioning action fails, or a policy does nothing after an extraction, the cause can be in several places: the target system's error, the values the action sent, or the policy's configuration. The LCM Run Analyst gathers that detail and explains it in plain language, so you can decide what to change. To write policy conditions and formatters, use the [LCM Policy Agent](/4yItIzMvkpAvMVFAamTf/features/access-agents/agents/lcm-policy-agent.md) instead. ## Capabilities The agent answers questions about what happened when a policy ran. It explains why one action failed and suggests a fix, summarizes how one policy's runs performed over a period, and diagnoses why a policy or one of its workflows did not run. Some questions the agent can answer: > "How did this policy's runs perform over the last 7 days?" > > "What do this week's failures have in common?" > > "Is this week worse than last week?" > > "How many accounts did this policy create this week?" > > "Is anything stuck or blocked now?" > > "Was this run an automatic retry?" > > "The integration extracted, but the Joiner workflow didn't run. Why?" ### Explain a failed run To open the agent on a failed record in [Activity](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/activity-log.md): 1. Go to **Lifecycle Management** > **Activity**. 2. Open the failed record from the **Workflow Tasks**, **Integration Jobs**, or **Events** tab. 3. In the error banner at the top of the detail view, select **Explain with AI**. The Access AI panel opens a new conversation with the LCM Run Analyst, with a question scoped to the record you opened. The banner appears in three detail views: * **Workflow Task** detail, when the task errored and recorded one or more messages. The banner reads **Task failed**. A task that was skipped, blocked, or completed with messages shows **Task skipped**, **Task blocked**, or **Completed with warnings** instead, without the button. * **Integration Job** detail, when the job recorded an error message. The banner reads **Job failed**. * **Event** detail, when the event has a message and did not succeed. The banner reads **Event failed**. The **Workflow Actions** tab detail view has no error banner, so open the underlying job from the **Integration Jobs** tab instead. **Explain with AI** is also hidden when a record carries neither a workflow task ID nor an action job ID, because every lookup the agent performs requires one of the two. #### What the agent reads For the run you opened, the agent reads: * **The action and its target**: the action name and type, the integration the action ran against, and the identity it ran for. * **The raw error the target system returned**, including any Veza context and application-specific error messages. * **The values the action sent.** Each value appears with both the Veza attribute name your policy configured and the target system's own property name. That pairing lets the agent quote the exact value behind an error such as `Invalid value specified for property 'mailNickname'`. * **Lifecycle Management's own recorded findings** for the run, when the run includes them. These can show which attribute collided and with which account, whether an identity was found, which attributes did not sync, and any alternative value a retry substituted. A recorded finding takes precedence over the error string. Sent attribute values are available for **Provision Account** (named **Sync Identities** in earlier releases), **Reset Password**, **Deprovision Account**, and **Create Email** actions, which record the resolved values they sent. For other action types, the agent explains the error without attribute values and says so, instead of offering theoretical values. #### What the explanation contains An explanation identifies the action that failed and the integration it targeted, states what the error means, and ties it to the specific value that produced it. It then suggests a resolution, such as correcting the value at the source or the attribute mapping or formatter that produced it, and says whether retrying the run is likely to help. The agent has built-in knowledge of provisioning errors for Active Directory and LDAP (including result codes, the sub-codes in error 49 bind and logon failures, and referrals), Microsoft Entra ID (Azure AD) through Microsoft Graph, and Okta. For other integrations, it explains what it can from the error text and the action, and stays within what the run recorded. A workflow task can fail before any action runs, so it has no target system error to explain. The agent answers these cases from the task's own state and messages: * A pre-flight validation failure or a policy configuration error, recorded on the task rather than on an action. * A [dry run](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/test-policies-with-dry-run.md), which sends nothing to the target system. * An attempt recorded as **Skipped** with an error. Lifecycle Management superseded it with a retry, so the error is real, but a later attempt might have succeeded. * A run your role cannot see, which the agent reports as not visible rather than as a run without errors. When a message carries no target system payload at all, such as a bare RPC error or a timeout, the agent identifies it as an internal Veza error and directs you to Veza Support instead of attributing it to your configuration. The conversation keeps the run you opened in context, so follow-up questions in the same thread stay on that run. To ask about a different run, open it and select **Explain with AI** from its banner. The agent does not reuse run identifiers from earlier in a conversation, because a stale identifier would return an answer about the wrong run. ### Summarize a policy's runs 1. In Lifecycle Management, open the [policy page](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policy-and-version-pages.md#policy-page). 2. In the top navigation bar, select **Toggle Access AI Panel** to open the Access AI panel. 3. In the agent selector, keep **Auto**, or select **LCM Run Analyst**. 4. Ask about the policy's runs over a period. To set the period, name it in minutes, hours, or days, or give a start and end time. | Question | What the agent returns | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | How runs performed | Counts of finished runs in the period by outcome: errored, completed, skipped, and abandoned. Runs still running or waiting are counted separately and are not limited to the period. | | Which runs failed | Failed runs in the period, newest first, with their messages. By default the agent lists errored runs, and it can also list skipped or abandoned runs. It lists 25 runs by default and up to 100. | | How many runs each workflow processed | Counts of finished runs in the period for each workflow, highest first. The counts are runs, not identities: an identity is counted again for every run. A workflow with no finished or unfinished runs does not appear. | | What has not finished | Runs that are running, waiting, or blocked by a safety limit, from any time rather than the period, longest-waiting first. It lists 25 runs by default and up to 100. A run scheduled for a future time is waiting by design. | | How a run started | For each failed or unfinished run it lists, whether an extraction triggered it, a user ran it manually, or it is an automatic retry of a failed run. | | How many accounts changed | Counts of accounts that the policy's runs created, updated, deprovisioned, and deleted in target systems in the period, and of deprovisions that failed, by integration. Failed creations and updates are not counted, and neither are mailboxes or changes made by access requests. | | What failures share | Failures grouped by cause. The agent groups errors whose messages match after removing values such as IDs, distinguished names, email addresses, quoted values, and timestamps. It returns 50 groups by default and up to 100. The scan stops after 1,000 actions and says the result is truncated. | | How long workflows took | The start time, end time, duration, and task counts for each workflow in the most recent runs: 3 runs by default and up to 10. Workflows can overlap, so their durations do not sum to the run's duration. | Run counts and failed-run lists link to the matching runs on the **Activity** page, and each unfinished run links to its own run. Account-change counts have no link. To compare periods, ask whether a period is better or worse than the one before it. The agent gives the same numbers for the preceding period of the same length and reports both without calling the difference a trend. ### Diagnose why a policy did not run Open the policy page and the Access AI panel as for a summary, then describe what did not happen. The agent runs three checks in order and leads with the first one that explains why nothing ran: | Check | What the agent reports | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The policy's configuration | Anything in the policy as it is configured now that stops workflows from running: the policy is disabled, a [safety limit](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md#when-a-safety-limit-is-reached) is holding it, it has no source of identity, it has no published version or the published version has no workflows, every workflow is disabled, or every enabled workflow skips the source that extracted. | | Whether the extractions arrived | For each source of identity, its most recent extractions in Lifecycle Management and what happened to each: 5 per source by default and up to 20. A processed extraction has had its tasks scheduled, which does not mean the workflows ran or succeeded. If no source has an extraction, the extraction did not complete or did not run, or the integration is not enabled for Lifecycle Management, and the agent cannot tell which. A policy with more than one source waits until every source has extracted. | | Where recent runs stopped | For the most recent runs (3 by default and up to 10), the step where the run stopped producing work. For each workflow, it reports whether no identity met the trigger condition, no identity had a change in the attributes the workflow watches, or no identity was due another run. Each workflow's counts cover that workflow only, so they do not add up to an identity count. | A new policy that has not finished its initial run records identities but runs no workflow. The agent reports this as expected, not as a failure. The checks report what the run's counts show, not individual identities, so they cannot say why one specific identity was or was not processed. To review a run step by step, open the policy's [run details](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md#policy-run-details). If a safety limit stopped the policy, see [Blocked Tasks](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md#blocked-tasks). ## Scope of an answer * **A run or a policy in context.** The agent needs a failed run or a policy to work from. Without one, it asks you to open the failed run or to provide a task or job ID. * **One policy at a time.** A summary or a diagnosis covers one policy: the open policy, or the policy of the failed run the agent was opened from. The agent does not compare policies. * **Up to 90 days.** A summary covers at most 90 days. If you do not name a period, the agent uses the last 24 hours. * **Current configuration.** A diagnosis checks the policy as it is configured now, so an older run might have run under a different configuration. The agent works from run and error data. It does not retry, re-run, or cancel runs, and it does not change policies. ## Where it appears in the product * **Activity** page: **Explain with AI** in the error banner of a failed workflow task, integration job, or event opens the agent on that record. * **Policy page**: The page has no dedicated button. Select **Toggle Access AI Panel** in the top navigation bar, then keep **Auto** or select **LCM Run Analyst** in the agent selector. ## Who can use the LCM Run Analyst * **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: Administrator, Operator, Viewer, Watcher, Access Reviewer, Access Reviews Admin, Access Reviews Monitor, Re-assigner, or NHI Security Admin. **Explain with AI** does not appear for a user without one of these roles. See [Roles](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md). * **Role-limited answers:** Workflow durations, whether the latest extractions reached the policy, and why a policy or workflow did not run require the Administrator, Operator, or Viewer role. Workflow durations cover every identity in the run. ### Which runs you can explain A role that includes Access AI lets you open the agent, but it does not widen which runs you can see. The agent reads each run with your own permissions, so it can explain and count only the runs you can open on the Activity page: * **Administrators and Operators** see every run of the policy. * **Users with any other role** see only runs for their own identity. The agent reports any other run as not visible. This also applies to summary counts, failed and unfinished run lists, and failure causes. ## Privacy, data handling, and audit Lookups use the permissions of the user asking, not an elevated service identity. ### How sent values are protected Values the agent reads pass through two controls before an explanation is composed: * **Credential masking.** An attribute whose name contains `password`, `secret`, `token`, or `credential`, or the whole word `key` or `keys`, has its value replaced with `` before it leaves Lifecycle Management. The agent reports that a credential was sent without showing it. * **Server error detail.** Detail from an internal failure is withheld. Only the status codes that Lifecycle Management writes for a caller to read, such as not found, invalid argument, permission denied, and canceled, carry their detail into an answer. For the privacy and data-handling model that every Access Agent shares, see [Privacy, data handling, and audit](/4yItIzMvkpAvMVFAamTf/features/access-agents.md#privacy-data-handling-and-audit). ## Related * [Veza Access Agents](/4yItIzMvkpAvMVFAamTf/features/access-agents.md) * [LCM Policy Agent](/4yItIzMvkpAvMVFAamTf/features/access-agents/agents/lcm-policy-agent.md) * [Activity](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/activity-log.md) * [Test Policies with Dry Run](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/test-policies-with-dry-run.md) * [Attribute Mapping](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/attribute-mapping.md) * [Attribute Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.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-run-analyst.md?ask=&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.