Workflow Triaging

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.

Each runbook-*.md above is a symptom section in the workflow-debugging 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:

If the user only provides host + time, respond with the generic workflow error searches and note that narrowing by model/instance ID will improve accuracy.

---

Step 3: Log patterns and Splunk (what to search)

Logs on 6.5 / AMS are accessible via direct filesystem (crx-quickstart/logs/error.log), AMS log access, or Splunk (if indexed).

Example Splunk searches — <your_aem_index> is a placeholder; substitute your organization's AEM log index:

• All workflow step errors (last 24h): index=<your_aem_index> "Error executing workflow step" | table _time host message | sort - _time
• Process not registered: index=<your_aem_index> "getProcess for" "failed" | table _time host message
• By workflow model or instance: index=<your_aem_index> ("Error executing workflow step" OR WorkflowException) (message=*<modelName>* OR message=*<instanceId>*) | sort - _time
• Lock contention: index=<your_aem_index> "refreshing the session since we had to wait for a lock" | table _time host message
• Thread pool exhaustion (auto-advance impact): index=<your_aem_index> "RejectedExecutionException" | table _time host message

Note: Index names, sourcetypes, and field names are environment-specific — they depend on how your AEM logs are onboarded to Splunk. There is no fixed index; confirm the correct one with whoever owns your Splunk onboarding before running these. Narrow by host, time range, model, and instance ID — both for accuracy and to avoid over-broad data exposure.

---