Workflow Triaging

AEM Workflow Triaging — Cloud Service

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 as a Cloud Service (AEMaaCS).

Audience

AEMaaCS developers and operators (and the IDE LLM acting on their behalf) classifying workflow incidents across one or more environments — using environment ID + time-range + Cloud Manager Logs (or a log aggregator such as Splunk, if you forward AEMaaCS logs there), before drilling into one instance. Use this skill for cross-environment log mining and symptom classification; switch to workflow-debugging once the instance and root cause are identified.

Variant Scope

• AEM as a Cloud Service only.
• Not for AEM 6.5 LTS / AMS. If the target is 6.5 LTS, stop and use the 6.5-lts variant of this skill — Splunk index/sourcetype paths, the JMX surface, and several log signatures there do not apply as written on AEMaaCS.
• Log access via Cloud Manager → Environments → Logs (download or streaming), or Splunk if logs are indexed there.
• No JMX on AEMaaCS production. Workflow counts and queue metrics come from logs, Developer Console status producers, and the Sling Job Console. JMX MBeans exist on the local AEMaaCS SDK (localhost:4502) but must not be assumed available on cloud environments.
• All remediation lands via Git + Cloud Manager pipeline. There is no Felix Console write access or Package Manager on production AEMaaCS environments.

Dependencies

• workflow-debugging — once a symptom is classified and an environment/instance is identified, route here for the step-by-step runbook and remediation.
• workflow-debugging/reference.md — canonical diagnostic tool pointers, log patterns, and external doc links for AEMaaCS.

---

When to use this skill

• User asks: "Workflow errors on <env-id> for the past X hours", "Workflow activity on <env-id>", "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 Cloud Service (environment ID format: cm-p<programId>-e<environmentId>).

---

Step 1: Classify symptom (symptom_id)

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

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. 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 environment ID + time, respond with the generic workflow error searches and note that narrowing by model or instance ID will improve accuracy.

---

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

Logs on AEMaaCS are accessed via Cloud Manager → Environments → Logs (download or streaming). The primary file is error.log. When logs are indexed in Splunk (or any log aggregator), use these patterns.

Example Splunk searches (replace index/sourcetype/field names for your environment):

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

Note: Indexes and sourcetypes vary by organization; adapt queries accordingly.

---