AEM workflows are sold as the safety net for content. In real newsrooms and brand teams, they can also be the bottleneck. The trick is turning the out of the box models into something editors actually use when the clock is ticking.
Today’s piece is about Adobe CQ5 slash AEM from the trenches. What works, what gets ignored, and the tiny tweaks that turn a clunky path into a smooth publish. No fairy tales, just what ships.
What problem are we actually solving?
Two things fight each other all day: speed to publish and risk of shipwreck. Editorial wants to go live now. Legal wants to sleep at night. AEM workflows sit right in that tug of war.
If your model adds steps without adding signal, it will be bypassed. People will tree-activate on Fridays and hope for the best. That is not a process. That is luck.
Who touches what?
Map the real actors first. Authors draft. Editors fix. Photo desk picks art. SEO checks titles. Legal blesses or kills. Sometimes product or compliance chimes in. That’s your swimlane.
Translate those roles into AEM groups not named people: content-authors, editors, seo-review, legal, dam-users, workflow-users. Assign participant steps to groups, not humans. Turnover will not break your model.
Where do we start without writing custom code?
Start with the out of the box Request for Activation model. Point the approval step to the editors group. That alone cuts down rogue publishes. Keep a second path called fast-lane for breaking news, routed to a smaller group of senior editors.
Make it boring and predictable. Authors hit “Start Workflow.” Editors get an inbox item and an email. Approve sends to publish. Reject returns with a comment. That’s your minimum viable gate.
How many steps is the sweet spot?
Three to five. Draft. Editorial review. Optional legal. Publish. That’s it. The rest is meetings. If a step can be done in parallel outside AEM, do it in chat or in your ticket. Don’t stack five participant steps just because you can drag them in the modeler.
Use status you can see. Add a simple property like reviewStatus on the page and surface it in Siteadmin list view. People trust what they can scan.
Inbox or email, which one wins?
The AEM inbox works, but people live in email. Configure the Day CQ Mail Service with your SMTP and tweak the notification templates under /etc/workflow/notification. Include deep links to the payload page and the comment thread.
Keep noise under control. Send to groups for fairness, but tell the group lead to triage fast. Nothing dies quicker than a mailbox full of “FYI.”
Classic UI or touch UI for authors?
Editors are faster in classic UI with the Sidekick right now. Touch UI is promising but still young. For deadlines, classic wins the day. Workflows run the same. Train against the screens people have muscle memory for.
Don’t flip the switch mid-campaign. Let people breathe.
What about assets? The DAM can melt CPUs.
Every upload wakes the DAM Update Asset workflow. Thumbnails. Metadata. Renditions. It’s handy but heavy. On busy days, it will chew through your author box like a blender.
Trim renditions you do not use. If you only need a 1400, 900 and a small thumb, remove the rest. Scope heavy steps by folder using a launcher path rule. Don’t OCR every PDF if you never search them. Your CPUs will thank you.
How do we keep cache sane after publish?
Replication should flush the Dispatcher right away. Use the flush agent on publish and be careful with tree activation on big folders. You can knock out cache and origin at the same time if you push thousands of invalidations in one shot.
Use scheduled activation for large drops. Stage it, test it, then flip with “Activate Later” at a quiet minute. Track statfiles. A quiet cache is a happy day for ops.
What about translations and multi site?
If you run multiple locales, set up MSM with Blueprints and Live Copies. Keep rollouts simple. Don’t auto roll author bios and media unless you intend to override every time. That burns both teams.
For translation, plug in your vendor connector when you have it. Until then, a manual translation project plus a workflow that locks pages and tracks status will do. Keep strings in i18n dictionaries and content in pages. That split saves rework.
Do we really need custom workflow code?
Write Java process steps only when a human cannot do the job or forgets it often. Set metadata, ping an API, create a version snapshot, post to a Slack-like thing if your team has one. The rest can live in participant steps.
Keep logic in OSGi services, not in ECMA scripts. Scripts look quick then rot. Services log better, test better, and won’t surprise you after a restart.
What does a sane editorial model look like?
Here’s a model that has shipped for me more than once:
Step 1: Author submits “Request for Activation.” The payload is the article page. Optional related assets are linked in comments.
Step 2: Editor review. Check title, deck, URL, tags, teaser, image alt. Either approve or reject with a short comment like “missing source” or “update hero.”
Step 3: Legal gate when needed. Only runs if a page property needsLegal is true. This keeps 90 percent of content moving. Legal sees a clean PDF preview link and the change summary.
Step 4: Pre-publish to stage. Replicate to a stage publish tier. QA can click through. A time limit of one hour escalates silently to the editor if nobody touches it.
Step 5: Go live. Publish to live and flush cache for the page and its list pages. Write a version label like published-YYYYMMDD-HHMM. Close the workflow.
This path keeps the chain short. Legal only shows up when tagged. Stage gives QA a look without slowing the main path.
How do we make it fast for humans?
Templates and preflight checklists. Add a visible checklist to the page editor: title length, meta description, canonical, tags, hero image, alt text, related links. That knocks out 80 percent of review feedback before it starts.
Use defaults that save clicks. Auto-populate the meta description from the deck. Auto-build the social image from the hero. Let editors edit, not babysit fields.
What blows up in production and how do we avoid it?
Zombie workflows. Heavy DAM queues. Endless inbox items. The usual.
Watch /var/workflow growth. Set the maintenance job to purge completed and aborted instances weekly. Keep a small history for audit and dump the rest before it eats disk. If a step fails, don’t edit a running model. Clone it, version it, switch the launcher to the new one.
For DAM, batch uploads off peak. Keep a dashboard of active workflows and CPU. If your asset workflow queue spikes during big photo drops, pause noncritical steps. People care about new hero images, not ten extra thumbnails nobody uses.
How do we handle timeouts and vacations?
Participant steps support timeouts and escalation. Set a 30 minute reminder for news, a 24 hour timer for evergreen. On timeout, reassign to a backup group like editor-on-call. Keep it automatic. Don’t hunt people down on launch day.
Also set vacation rules via group membership. People leave on Friday. Your model should not.
What about audit and trust?
Use the workflow comment thread as the audit log. Be strict about adding a one line reason on rejection. Tie that to the page version that went live. If something goes sideways, you can roll back and explain it in one screenshot.
Don’t put secrets in workflow metadata. Comments live. Logs live longer.
How do we keep search and social happy without detours?
Make SEO part of the editorial step, not a separate approval. Enforce URL rules and canonical fields in the component dialog. Give editors a live preview of title and description length. Bake it in. No new path needed.
For social, include Open Graph fields next to meta. Pre-fill from the hero and deck. That saves the share image scramble when a story pops.
How do roles meet permissions without turning into a maze?
Keep your ACLs simple: authors write under their section, editors can activate across sections, legal can view everything but does not modify content. Workflow participant steps do the rest. Permissions are the floor, not the process itself.
Sync groups from LDAP if you have it. Map once. Avoid one-off local users unless you enjoy weekend pages.
How do we avoid tying every business rule to a workflow?
If a rule changes every week, keep it in content or config. Workflows are good for gates and handoffs, not for product pricing or copy tone. Put those in components or services and let the model stay calm.
Use checklists over gates when the risk is small. Gates are for things that break trust when missed: legal, compliance, personal data, money.
What about speed during breaking news?
Set up a “breaking” template that bypasses legal, pushes to a featured slot, and expires in 24 hours unless edited. That keeps the front page fresh without locking the main desk. Editors own the switch. You can sleep later.
Also keep a fast publish lane tied to a small group with pager duty. One inbox, one decision, live in seconds. Use it only when flagged.
How do we train people so this sticks?
Run a one hour session with real stories. Start a workflow. Reject it. Approve it. Republish a fix. Restore a version. Clear cache on a page. That muscle memory beats a wiki page.
Post a one pager cheat sheet with the five checks before approve: title, deck, URL, image alt, tags. Tape it to monitors. Done.
Can we measure if this is working?
Yes. Track time from submit to publish. Track rejection rate by reason. Watch average workflow duration by section. If your legal step is stalling lifestyle content but never finds an issue, cut it from that path.
Keep an eye on workflow queue sizes and DAM processing time. If queues stack during known drops, schedule or add horsepower during those windows. Data beats feelings.
What do we do when things jam?
Have a “red phone” playbook. If a publish must go out and the model is stuck, the duty editor can activate and log the reason. After the storm, fix the model or the launcher. Don’t shame people for shipping during a jam.
Reassign stuck steps quickly. Orphaned tasks happen when people leave or go offline. Give desk leads rights to reassign without IT tickets.
Compact wrap up
AEM workflows shine when they mirror how your team already moves. Short paths, clear owners, obvious status, smart defaults. Use out of the box pieces first. Add code only where humans stumble.
Trim the DAM. Watch /var. Flush with care. Escalate on timeouts. Legal when needed, not by habit. Teach the flow with real stories and measure turn times, not just button clicks.
Real editorial teams publish under pressure. Build your model for that moment. If it helps on a frantic Tuesday afternoon, you nailed it. If it only looks good in a demo, keep tuning until the desk nods and keeps using it.