plugins/aem/cloud-service/skills/aem-workflow/workflow-triggering/SKILL.md
Start AEM Workflows on AEM as a Cloud Service using all available triggering mechanisms. Use when starting workflows manually via the Timeline UI, programmatically via WorkflowSession.startWorkflow(), via the HTTP Workflow API, through Manage Publication, or passing initial metadata and payload to a workflow instance.
npx skillsauth add adobe/skills workflow-triggeringInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
All mechanisms to start a workflow on AEM Cloud Service — from UI, programmatic API, HTTP API, and Manage Publication.
workflow-starter)
to a service user that is a member of the workflow-process-service group
(workflow-process-service is a group, not a user). See
programmatic-api.md for the mapping config.| Mechanism | Use Case |
|---|---|
| Timeline UI | One-off manual start on a single page or asset |
| Manage Publication | Multi-page batch start, integrates with publish pipeline |
| WorkflowSession API | Backend Java code, scheduled jobs, event handlers |
| HTTP Workflow API | REST calls, scripts, external integrations |
| Workflow Launchers | Automatic on JCR events — see workflow-launchers skill |
The workflow starts with the selected item as JCR_PATH payload and the current user as initiator.
AEM creates a cq:WorkflowContentPackage containing all selected pages as the workflow payload.
The payload is a JCR_PATH pointing to the generated package node under /var/workflow/packages
(legacy: /etc/workflow/packages) — useful to know when debugging payload issues, since the
payload is the package node, not the individual pages.
@Component(service = MyWorkflowService.class)
public class MyWorkflowService {
@Reference
private ResourceResolverFactory resolverFactory;
public String startWorkflow(String payloadPath, String modelId,
Map<String, Object> initialMeta) throws Exception {
Map<String, Object> auth = Collections.singletonMap(
ResourceResolverFactory.SUBSERVICE, "workflow-starter");
try (ResourceResolver resolver = resolverFactory.getServiceResourceResolver(auth)) {
WorkflowSession wfSession = resolver.adaptTo(WorkflowSession.class);
WorkflowModel model = wfSession.getModel(modelId);
WorkflowData data = wfSession.newWorkflowData("JCR_PATH", payloadPath);
// Set initial metadata
MetaDataMap meta = data.getMetaDataMap();
if (initialMeta != null) {
initialMeta.forEach(meta::put);
}
Workflow instance = wfSession.startWorkflow(model, data);
return instance.getId();
}
}
}
Model ID format: /var/workflow/models/my-workflow (the runtime path, not the design-time path)
The API is rooted at /var/workflow/instances. Do not POST to /api/workflow/instances —
no workflow servlet is mounted there, so the Sling default POST servlet silently writes stray JCR
nodes and returns a misleading 2xx without starting any workflow.
# Start a workflow — returns HTTP 201 with an HTML body linking to the new instance path
curl -u admin:admin -X POST \
"http://localhost:4502/var/workflow/instances" \
--data-urlencode "_charset_=utf-8" \
--data-urlencode "model=/var/workflow/models/my-workflow" \
--data-urlencode "payloadType=JCR_PATH" \
--data-urlencode "payload=/content/my-site/en/home" \
--data-urlencode "workflowTitle=Review Request from CI" \
--data-urlencode "startComment=triggered via HTTP API"
# The start response is HTML — parse the instance path from the
# <a id="Location"> anchor (or "Modified Resource" link in the body),
# e.g. /var/workflow/instances/server0/<date>/my-workflow_1
# List all instances (JSON)
curl -u admin:admin "http://localhost:4502/var/workflow/instances.json"
# List by state using a selector (.RUNNING.json, .SUSPENDED.json, .COMPLETED.json, .ABORTED.json)
curl -u admin:admin "http://localhost:4502/var/workflow/instances.RUNNING.json"
# Get instance details — JSON fields: id, state, initiator, startTime,
# model, payloadType, payload, workItems[]
curl -u admin:admin \
"http://localhost:4502/var/workflow/instances/server0/<date>/my-workflow_1.json"
# Suspend a running workflow — POST state=SUSPENDED, returns HTTP 200
curl -u admin:admin -X POST \
"http://localhost:4502/var/workflow/instances/server0/<date>/my-workflow_1" \
--data-urlencode "_charset_=utf-8" \
--data-urlencode "state=SUSPENDED"
# Resume a suspended workflow — POST state=RUNNING, returns HTTP 200
curl -u admin:admin -X POST \
"http://localhost:4502/var/workflow/instances/server0/<date>/my-workflow_1" \
--data-urlencode "_charset_=utf-8" \
--data-urlencode "state=RUNNING"
# Terminate (abort) a workflow — POST state=ABORTED, returns HTTP 200
curl -u admin:admin -X POST \
"http://localhost:4502/var/workflow/instances/server0/<date>/my-workflow_1" \
--data-urlencode "_charset_=utf-8" \
--data-urlencode "state=ABORTED" \
--data-urlencode "terminateComment=cleanup"
workflowTitle when starting programmatically — it helps operators identify instances in the console./var/workflow/models/ path (runtime). Do not use the /conf design-time path./var/workflow/models/ before calling startWorkflow().tools
Use the run-workflow MCP to discover, compose, execute, publish, and save Adobe Firefly workflows. TRIGGER when: user asks what actions are available, what the MCP can do, how to process images/video/3D via workflow, wants to build/run/save/publish a workflow, OR pastes any workflow/batch/execution ID. BARE ID (UUID/workflowId/batchId) = INSPECT ONLY — call inspect_run, NEVER run_workflow_submit. ALWAYS call list_actions first for capability/discovery questions. DO NOT TRIGGER for direct Firefly API calls without MCP (use firefly-api-specs).
tools
Run predefined featured workflows via run-workflow MCP. TRIGGER when user names a featured workflow (retargeting, banners at scale, localization, packaging, banner advertising, etc.) or asks to run a known marketing/production workflow. Requires run-workflow MCP. ALWAYS call get_featured_workflow before compose_workflow. DO NOT TRIGGER for custom one-off workflows with no named template — use run-workflow skill.
tools
Migrate an Adobe Commerce App Builder project from the Integration Starter Kit or Checkout Starter Kit to the new App Management approach. Run from the root of the App Builder project to be migrated. Pass --auto to skip confirmation prompts (suitable for CI or batch use) — auto mode prints a summary of all Q&A questions answered with their defaults. Pass --doc-scan-only to scan README.md and env.dist for outdated content without modifying any files. Use when the user wants to migrate an App Builder project from the Integration Starter Kit or Checkout Starter Kit to the App Management approach, or mentions upgrading their Adobe Commerce extension architecture.
development
Add or modify webhook interceptors in an Adobe Commerce app. Use when the user wants to intercept Commerce operations to validate input, append data, or modify behavior — before or after execution. Requires a base app initialized with commerce-app-init.