Magnolia CMS Workflow explained: the Big Picture

Magnolia CMS combines 3 frameworks together to support workflows in its recent version: JBPM, Magnolia Task+Pulse and Magnolia itself (command, actions, dialogs..).
You can find more infos on those topics on the official Magnolia Workflow documentation page.

But in short words, how does it work?

Magnolia CMS editors (kind and polite people, I guarantee..) usually open their browser and produce some content. Once ready, they need to ask for approval to their boss in order to see content going live.

Editors starts the workflow from the “pages” app:

They can add a comment or even schedule the content publication:

Once saved, the workflow is initiated: (usually) other users, so called “publishers”, are notified by The Pulse, the internal communication BUS offered by Magnolia: so, they need to “claim” this Task:

Once they are sure that everything is ok, they approve editor’s intention:

And now the content goes live:

This is the “direct lane”, where there is no bounces between publishers and editors (yes, a publication workflow can last forever). For simplicity, I have omitted other scenarios.
But now, what happen behind the scenes? How the Magnolia CMS modules interacts each other to orchestrate the activation workflow?

This is the Magnolia CMS Workflow Big Picture:

And here the details:

1. Editors launch an action. This action, available in “pages” app, extends another action, available inside the workflow module for consistency. Activate actions, in few words, launches the activation command. In Community Edition this command directly activate the content, but in Enterprise Edition is overwritten by workflow module: it calls..another command (acting as delegate), the “workflow-activate” one. This command has 2 main goals:
   1. Version the content, to avoid to activate further content changes
   2. Launch the activation flow against the versioned content (and with user parameters as “storage” of flow data)
2. The reviewForPublication workflow now runs on JBPM Workflow Engine and stops once a HumanTask is required
3. Publishers (any!) now claims the Task. Now only he / she can approve / reject the activation.
4. Finally content is activated according to Personalization way-of-doing: the Personalization module has its rules and once installed, injects itself inside the Workflow module

Some pictures: