Session 9 — Workflows, launches & content operations
Purpose: Learn how content moves through review, approval and scheduled publication — the operational life of a page after you build it.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Components live inside content processes; know them |
| Tech leads | Governance hooks live here |
Workflows: CI pipelines for content
An AEM workflow is a modelled, multi-step process over a payload (usually a page or asset): steps, participants (human approval), and process steps (automation). Think a CI pipeline where the artefact is content.
Author edits PHI plan page
│ submits
▼
┌───────────────────┐ approve ┌──────────────────┐
│ Review step │──────────▶│ Publish step │──▶ replication ──▶ publish tier
│ (compliance group) │ │ (process step) │
└───────────────────┘ reject └──────────────────┘
│◀───────────────┘
back to author with comment| Workflow concept | Meaning |
|---|---|
| Model | The process definition (steps, transitions) — /conf, editable in UI |
| Payload | The content the instance runs on |
| Participant step | A human task assigned to a user/group |
| Process step | Java/ECMA automation (e.g. activate page, generate renditions) |
| Launcher | Auto-start rule (e.g. on DAM upload → asset processing workflow) |
Out of the box you will meet: Request for Activation (author lacks replicate rights → approval flow) and the DAM Asset workflows (renditions/metadata on upload).
Launches: long-running content branches
A Launch is a copy of a page tree created for a future change — e.g. next quarter's PHI premium updates — kept in sync with ongoing edits to the source, then promoted on go-live day. Mentally: a long-running feature branch with automatic rebase, for content.
| Use | Tool |
|---|---|
| Future-dated campaign/pricing change across pages | Launch |
| Single page going live at a set time | On/Off times (scheduled (de)activation) |
| Emergency unpublish | Unpublish/Deactivate now |
Content ops you will be asked about
- Scheduled activation uses on/off times honoured by publish; the dispatcher must not cache pages past their off-time (TTL discipline).
- Versioning: every activation creates a version; authors can restore. Versions live in /var — they are ops-relevant (growth).
- Audit log records who did what to the page — first stop in "who changed this?" incidents.