AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified Apache-2.0 Self-run

Workflow Model Design

skill-adobe-skills-workflow-model-design · by adobe

Design and create AEM Workflow models on AEM as a Cloud Service. Use when creating workflow models via the Workflow Model Editor or content package XML, defining step types (PROCESS, PARTICIPANT, DYNAMIC_PARTICIPANT, OR_SPLIT, AND_SPLIT), configuring step properties, declaring workflow variables, and deploying models through the Cloud Manager pipeline.

No reviews yet
0 installs
25 views
0.0% view→install

Install

$ agentstack add skill-adobe-skills-workflow-model-design

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-adobe-skills-workflow-model-design)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Workflow Model Design? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Workflow Model Design (Cloud Service)

Design workflow models for AEM as a Cloud Service: step structure, transitions, OR/AND splits, variables, and model XML deployment.

Audience

Developers (and the IDE LLM acting on their behalf) authoring AEM workflow models for AEM as a Cloud Service — designing the step graph, splits, joins, transitions, and the model XML that ships through the Cloud Manager pipeline.

Variant Scope

  • AEM as a Cloud Service only.
  • Models are stored at /conf/global/settings/workflow/models/. Do not write to /libs or /etc/libs is immutable and /etc/workflow/models/ is the legacy 6.5 path, deprecated on AEMaaCS.
  • Deploy via Cloud Manager pipeline; design-time → runtime sync is required after deploy (Tools → Workflow → Models → Sync).
  • Not for AEM 6.5 LTS. If the target is 6.5 LTS, stop and use the 6.5-lts variant of this skill — /etc/workflow/models/ legacy auto-deploy and mvn install -PautoInstallPackage deploys documented there do not apply on AEMaaCS.

Dependencies

  • workflow-foundation references (architecture, API, JCR paths, Cloud Service guardrails) — load alongside.
  • workflow-development — every PROCESS step in the model needs a WorkflowProcess (or process.label) registered as an OSGi service. Model XML and Java code are co-authored.
  • workflow-launchers — when a launcher routes content into the model, see launcher-side guardrails.

Workflow

Model Design Progress
- [ ] 1) Clarify the workflow purpose: what triggers it, what steps are needed, who approves
- [ ] 2) Map out steps: PROCESS (auto), PARTICIPANT (human), OR_SPLIT (decision), AND_SPLIT (parallel)
- [ ] 3) Decide payload type: single JCR_PATH page/asset, or multi-page via workflow package
- [ ] 4) Identify workflow variables needed for inter-step data passing
- [ ] 5) Design model XML: flow/parsys layer with correct nt:unstructured step components and sling:resourceType per step
- [ ] 6) Add filter.xml entry with mode="merge" for the model path
- [ ] 7) Deploy via Cloud Manager pipeline
- [ ] 8) Open the model in Tools → Workflow → Models → Edit → Sync; verify the model appears in /var/workflow/models/ and all steps render on the editor canvas
- [ ] 9) Start a test workflow instance; confirm it runs to completion

Output Contract

Generate only these files for a /conf-based model:

| File | Node type | Purpose | |---|---|---| | jcr_root/conf/.../models//.content.xml | cq:Page | Model root page | | jcr_root/conf/.../models//jcr:content/.content.xml | cq:PageContent | Title, template, resourceType | | jcr_root/conf/.../models//jcr:content/flow/.content.xml | nt:unstructured + parsys | Step nodes |

Never generate — hard stops:

  • Any file under jcr_root/var/ — AEM Sync writes /var/workflow/models/ automatically after you click Sync in the editor. Never ship /var content in a content package.
  • A model/ directory inside jcr:content/ at the /conf path — a cq:WorkflowModel node with ` and is the runtime format. It must never appear under /conf`. The Workflow Model Editor cannot open a model that contains it.
  • ❌ **` in filter.xml** — /var is never a package filter target. The only filter entry needed is the /conf` path.
  • Any path under /etc/workflow/models/ — deprecated and unsupported on AEM as a Cloud Service.

filter.xml — correct entry:

Node Types Quick Reference

| Type | Purpose | Key metaData property | |---|---|---| | START | Entry point | — | | END | Terminal | — | | PROCESS | Auto-executed Java step | PROCESS = FQCN or process.label | | PARTICIPANT | Human task (static assignee) | PARTICIPANT = principal name | | DYNAMIC_PARTICIPANT | Human task (runtime assignee) | DYNAMIC_PARTICIPANT = chooser.label | | OR_SPLIT | One branch selected by rule | Transition rule = ECMAScript (Rhino) | | AND_SPLIT | All branches execute in parallel | — | | AND_JOIN | Wait for all parallel branches | — | | EXTERNAL_PROCESS | Poll an external system | EXTERNAL_PROCESS = FQCN |

Default Path Rule

Unless the user explicitly names a specific AEM site, always generate models at /conf/global/settings/workflow/models/. Do not infer a site-scoped path (e.g., /conf/wknd/…) from conversational context such as "for the WKND site" or "install on the WKND instance." Workflow models are not site-scoped by default — they are global resources. Only use /conf//settings/workflow/models/ when the user explicitly states that the model should be scoped to a specific site.

Cloud Service Deployment

  1. Place model XML at: conf/global/settings/workflow/models//.content.xml (the flow/parsys design-time format — not jcr:content/model/)
  2. Add to ui.content package with filter.xml entry mode="merge"
  3. Deploy via Cloud Manager pipeline
  4. Open Tools → Workflow → Models → select model → EditSync
  5. Verify the model appears in /var/workflow/models/ via CRX/DE and all steps render on the canvas

Design-time vs runtime paths: /conf/global/settings/workflow/models/ stores the editor's flow/parsys format — this is what you author and deploy. Steps are nt:unstructured nodes with sling:resourceType; no cq:WorkflowNode or cq:WorkflowTransition nodes appear here. /var/workflow/models/ holds the runtime copy generated by Sync — it uses cq:WorkflowModel, cq:WorkflowNode, and cq:WorkflowTransition. Never write cq:WorkflowModel nodes to the /conf path, and never hand-author /var content — AEM manages the runtime layer entirely via Sync.

References

  • [step-types-catalog.md](./references/workflow-model-design/step-types-catalog.md) — complete step type reference with XML snippets
  • [model-xml-reference.md](./references/workflow-model-design/model-xml-reference.md) — full model XML structure and property reference
  • [model-design-patterns.md](./references/workflow-model-design/model-design-patterns.md) — common design patterns: linear, decision, parallel, loop-back
  • [architecture-overview.md](./references/workflow-foundation/architecture-overview.md)
  • [jcr-paths-reference.md](./references/workflow-foundation/jcr-paths-reference.md)
  • [cloud-service-guardrails.md](./references/workflow-foundation/cloud-service-guardrails.md)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

  • Author: adobe
  • Source: adobe/skills
  • License: Apache-2.0
  • Homepage: https://www.adobe.com/ai/overview.html

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.