How to Enable Request for Activation and Deactivation Workflows in AEM

This October marked the 15th anniversary of the acquisition of Day Software by Adobe. Thats when CQ5, Day Software's flagship product, came under Adobe's umbrella. And would later get rebranded to Adobe Experience Manager. A lot of things have changed since then. Features have come and gone. And in recent years AEM's architecture has transformed into a cloud architecture.

Which got me thinking about one of the oldest features in AEM. The workflow engine. Even with the advent of Workfront, AEM's internal workflow engine still plays a vital role.

Today I will go over the two request for activation & deactivation workflows. How to customize them. And how to ensure content authors use them. Ensuring content is peer-reviewed before it gets published.

ℹ️ As I dig into Adobe documentation looking answers, I bump into interensting stuff. For example, I know that activate/deactivate, publish/unpublish, and replication are interchangeable. I thought it was a bit funny when the documentation called it out. In case you didn't know.

• Publish / Unpublish These are the primary terms for the actions that make your content publicly available on your publish environment (or not).

• Activate / Deactivate These terms are synonymous with publish/unpublish.

• Replicate / Replication These are the technical terms describing the movement of data (for example, page content, files, code, user comments) from one environment to another such as when publishing or reverse-replicating user comments.

Setting Up The Users & Groups

For this demo, we will need two groups, and a couple of users. For this basic scenario, the mysite-authors will be responsible for content authoring. And they will lack the ability to publish content. Instead, they will need to request activation (or deactivation) via workflows. Which will get assigned to the mysite-reviewers. Who will receive a notification in their inbox and be able to complete the workflow.

Here is a sample RepoInit script to setup the users and groups

Customizing the Workflows

Out of the box, AEM comes with these workflow models. You can find them under Tools > Workflow > Models. Each of them is marked with a Default label. And the model located under /libs/settings/workflow/models.

• Request for Activation

  • /libs/settings/workflow/models/request_for_activation

• Request for Deactivation

  • /libs/settings/workflow/models/request_for_deactivation

Out of the box, they are not very useful. You need to edit these default workflow models for the first time. Which will copy them to the /conf/global/settings/workflow/models folder. And bump the version.

• /conf/global/settings/workflow/models/request_for_activation

• /conf/global/settings/workflow/models/request_for_deactivation

⚠️ I can't tell you how to design you publishing workflows. That depends on your business requirements. What I have devised here is a simple scenario. In which a content author can not publish without getting approval from a reviewer.

The only change we will make is to change the group on the "Approve content" participant step. Set my-reviewers as the participant group. And don't forget to sync the runtime model.

Requesting Activation & Deactivation

In the script above, authors inherit the permissions assigned to content-authors and workflow-users. But got denied the crx:replicate on /content/mysite. So, authors will see the "Request Publication" and "Request Unpublication" options. As opposed to the "Publish Page" and "Unpublish Page" that other authors would see.

When the author requests a publication, the publication wizard will gather all the unpublished references. And prompt for a scheduled time and title for the workflow.

And the reviewer would see the workflows in their inbox.

Manage Publication

In this scenario above, there were 27 unpublished payloads. Including template, content policies and assets. This is because I am using a new project archetype. In a real environment, all these would have gotten published already. And only the page and a few assets might need activation.

For a large number of references, the "Manage Publication" feature is preferable.

If the user lacks the ability to replicate, the Manage Publication wizard will prompt for a workflow title. Notice the name of the workflow it will use: "Request for Activation" (or Deactivation).

A single content package will get generated, and placed into the workflow. Making this method better suited content with a large number of references.

Conclusion

The request workflows are part of the page editor and multi-site manager. Their paths will always be

• /conf/global/settings/workflow/models/request_for_activation

• /conf/global/settings/workflow/models/request_for_deactivation

You will not be able to change this location. But you can edit and customize them to fit your publishing requirements.

Restricting who can publish content may seem restrictive at first. But it is like pull-requests for application code. Someone writes a new feature. And at least one other person should review it. So it should be the same for content.