/workflow-triaging

name: workflow-triaging
description: Triage AEM Workflow issues on AEM 6.5 LTS and AMS by classifying symptoms, gathering the right logs and metrics, and mapping to runbooks or Splunk searches. Use when the user asks for workflow activity/errors on a 6.5 host, needs to classify a Jira ticket, or wants to know what to collect for workflow debugging.
license: Apache-2.0

AEM Workflow Triaging — 6.5 LTS / AMS

Classify workflow issues, determine what logs and data to gather, and map to the correct runbook or log search. Optimized for **production support** on **AEM 6.5 LTS** and **Adobe Managed Services (AMS)**.

Audience

AEM 6.5 LTS / AMS operators and developers (and the IDE LLM acting on their behalf) classifying workflow incidents across one or more hosts — using host + time-range + logs (direct filesystem, AMS log access, or Splunk) and read-only JMX metrics, before drilling into a single instance. Use this skill for cross-host log mining and symptom classification; switch to `workflow-debugging` once the instance and root cause are identified.

Variant Scope

• This skill is **6.5-lts-only** (includes AMS).
• Log access via direct filesystem (`crx-quickstart/logs/error.log`), AMS log access, or Splunk (if indexed).
• JMX available via Felix Console (`/system/console/jmx`) or a JMX client for workflow counts, queue metrics, and remediation.
• **Not for AEM as a Cloud Service.** If the target is AEMaaCS, stop and use the cloud-service variant of this skill — JMX is not available on cloud production, logs are accessed via Cloud Manager (not the filesystem), and remediation lands through Git + pipeline rather than Felix Console. Several signatures and diagnostic surfaces here do not apply as written on AEMaaCS.

Dependencies

• `workflow-debugging` — once a symptom is classified and a host/instance is identified, route here for the step-by-step runbook and remediation.
• `workflow-debugging/reference.md` — diagnostic tool pointers, JMX/config locations, log patterns, and external doc links for 6.5 LTS / AMS.

---

When to use this skill

• User asks: "Workflow errors on <host> for the past X hours", "Workflow activity on <host>", "Why did workflow X fail?", "What should I collect to debug this workflow ticket?"
• User needs: Symptom classification, log patterns to search, Splunk queries, or required inputs for a runbook.
• Context: AEM 6.5 LTS / AMS (author/publish hostname format).

---

Step 1: Classify symptom (symptom_id)

Map the user's description to a **symptom_id** and runbook.

| User says / observes | symptom_id | Runbook | |----------------------|------------|---------| | Workflow not moving to next step; stuck in Running | workflow_stuck_not_progressing | runbook-workflow-stuck.md | | Task should be in Inbox but is not visible | task_not_in_inbox | runbook-task-not-in-inbox.md | | Workflow should start automatically but no instance created | workflow_not_starting_launcher | runbook-launcher-not-starting.md | | Workflow in Failed state or step shows error | workflow_fails_or_shows_error | runbook-workflow-fails-or-shows-error.md | | Step failed after retries; failure item in Inbox | step_failed_retries_exhausted | runbook-failed-work-items.md | | Instance Running but no current work item (inconsistent) | stale_workflow_no_work_item | runbook-stale-workflows.md | | Too many instances; slow queries; disk/repo bloat | repository_bloat_too_many_instances | runbook-purge-and-cleanup.md | | User cannot see work item or complete/delegate/return | user_cannot_see_or_complete_item | runbook-inbox-and-permissions.md | | Cannot delete workflow model (running instances) | cannot_delete_model | runbook-model-delete-and-update.md | | Jobs queued a long time; slow completion; queue depth high | slow_throughput_queue_backlog | runbook-job-throughput-and-concurrency.md | | Auto-advance / timeout jobs not firing; participant step stuck past its configured timeout | workflow_auto_advance_failure | runbook-job-throughput-and-concurrency.md | | New or changed workflow not starting or step not executing | workflow_setup_validation | runbook-validate-workflow-setup.md |

> Each `runbook-*.md` above is a symptom section in the [`workflow-debugging`](../workflow-debugging/SKILL.md) skill, not a separate file to open. That skill's Step 1 maps every `symptom_id` to a first action, and its numbered steps are the runbook body. Classify here, then hand off there.

> **WorkItem vs. TaskManager task — do not confuse these.** Most workflow Inbox items are workflow work items (`WorkItem`), created by Participant steps and managed by the workflow engine; they are stored under `/var/workflow/instances`, not in TaskManager. TaskManager (`/var/taskmanagement/tasks`) only holds tasks created explicitly via the Task API — used by Projects, Assets tasks, and custom integrations. Both paths are browsable in CRXDE Lite. For `task_not_in_inbox` and `user_cannot_see_or_complete_item` symptoms on a workflow: investigate the Participant step assignee configuration, Inbox filters, and workflow permissions — not TaskManager storage. Diagnosing the wrong backend wastes significant time.

---

Step 2: Required inputs for triage

Before suggesting a runbook or Splunk search, try to obtain:

| Input | Purpose | |-------|---------| | **Host / instance** | Author/publish hostname (e.g. an AMS `author`/`publish` host, or on-prem hostname). | | **Time range** | e.g. "past 4 hours", "past 10 hours" – for log/Splunk scope. | | **Workflow model or step name** | e.g. "Dynamic Media Reupload", "DAM Update Asset", "testmodel". | | **Instance ID** (if known) | From Workflow Console URL or payload; ties logs to one instance. | | **Payload path** (if known) | e.g. `/content/dam/...`; for path-related errors. | | **Log source** | Splunk index/sourcetype, direct filesystem `error.log`, or AMS log request. |

If the user only provides host + time, respond with the **generic** workflow error searches and n