The Magnolia Workflow module provides a standard four eye content approval workflow preconfigured on the Pages app. The name "four eye" comes from the fact that first an editor will create the content and then a publisher will approve the content. In the standard workflow the publisher has the ability to approve or reject based on his review of the content. In the event of a rejection the workflow will move into a revision cycle where comments can be passed to the editor about reasons for rejection.
The four eye workflow can best be understood using a diagram. Here we see the previously mentioned editor and the publisher, Eric and Peter.
Steps of the four eye workflow
Content creation or update
Whenever content is created or updated it's common for that content to go through an approval workflow before making it to public. That might involve creating a brand new page or updating an image or adding a new entry into a content app or something else.
Remember the workflow is only configured on the Pages app. However, it can be configured on the Assets app or any content app. See Enabling workflow in content apps.
Let's look at the example of creating a new page in the Pages app. Here we see Eric has created a new page named
From the status column we can see the new page shows a red dot. This indicates that this page exists on author but not on public. A green dot indicates that the page exists both on author and public and they are in sync. A yellow dot indicates that the page exists on both author and public but the current state on author is different the current state on public. In other words, a yellow dot indicates the page has been edited.
When the page or other content has finished it's editorial phase it's then time to activate that content.
The Review for Publication workflow is initiated from the actionbar using the Publish action. This will trigger the Submit for Publication dialog. The editor can submit a comment to be seen by the publisher and schedule a publication date and time.
It is also possible to Unpublish a previously published page. However, this too also goes through a workflow. The steps for unpublishing are very similar to the steps of publishing. You may also a schedule the unpublication date.
Once Eric clicks the publish button the workflow is started and a task is created for members the publishers group.
Groups for publication tasks are configured in
Tasks are used when there is a human interaction needed with the system. Magnolia registers the tasks
unpublish in the workflow jbpm integration module. These tasks are defined in configuration but used by the workflow. The workflow will call them by name and use the parameters set as properties.
If you wanted to have a different publishing group based on content path (or site) then see the tutorial Different Publishers Per Path Workflow for inspiration.
Before content makes it to public it must be reviewed by the editor.
When Peter logs in he will see a notification in the pulse for the task created by Eric.
Double click on the task to see the details in the message view. The message view show the details of the task and actions which can be performed on the task.
From this message view a user can take these actions:
- Assign to me - Tasks have a clear status and an assignee. To take any further action on the task you must first assign it to yourself.
- Approve and publish - If Peter is happy with the current state of the content he can now publish that content to the appropriate public instances.
- Reject - If Peter is not happy with the content then he rejects it. He also has the option to provide a rejection message to Eric.
- Abort - Take no decision on the content. Instead just abort the workflow altogether. (The feature was added in Magnolia 5.4)
- Preview page - Look at the content before making a decision to approve/reject/abort.
- Show changes - Compare the content to previous versions
The message view shown above is configured in the pages app here
/modules/pages/messageViews/publish. There is a message view configured for
unpublish which extend from the workflow module here
If you add workflow to a content app then you will want to create a message view for it.
The message views are then configured to the task here
viewMapping configuration tells the system which
messageView to display when viewing the details of the task. This is configured on a workspace by workspace basis or using a default.
The final step in the workflow process is the transfer of content from author to those public instances which should receive that content.