Adobe CQ / AEM: Customize the workflow on Activate

Question

This is my current understanding of the events on pressing the Activate button:

If the user has replication permission, the content is sent to the dispatcher. If the user does not have replicate, the Request for Activate workflow is run. Out of the Box this performs two steps which are both sent to the Administrators group.

If I change the OOB Request for Activation workflow to assign to another group then this group gets the message in their CQ Inbox instead.

My requirement is that I have multiple websites belonging to different divisions within the company, meaning that each has separate groups for users who can only author content and users who can Approve/Activate that content. In one case there is an additional requirement for the content in the careers section to be approved by the HR team only.

How can I alter the workflow to achieve these requirements?

Answer 1

I can think of two ways of doing this:

1) Change the OOB box workflow to use OR steps to switch to differnt groups based on the content path. This could get very complex when dealing with pages for both pages and assets, and the special conditions like the careers example.

2) Create a custom step that runs Java code that uses the AccessControlManager class to look for replicate permissions on the node, and if there aren't any then to traverse up the tree until it finds a node with permissions.

Answer 2

I've gone with option 1) for a similar problem.

If your main concern is having too many branches in your OR Split, maybe there's an opportunity to break down the workflow's decisions into multiple steps, instead of having one decision point where it branches out to many different paths.

For example, you might first split by what site the payload is on, and then split again based on user type, or section of the site. So, something like:

site 1

• section 1
  • role 1
  • role 2
• section 2

site 2

... and so on, where each level of indentation represents a separate OR Split.

If you use the Container Step to trigger a sub-workflow at each of these decision points, that may help keep your workflow more organised.

Because I didn't love the idea of changing the OOB Request for Activation workflow, I minimised that by making the first step an OR Split that does a generic check - basically:

Pseudo-code:
if (we're in one of the sites that's subject to my custom workflows) {
  Container step that points to my main custom workflow;
} else {
  Continue with the default Request for Activation workflow steps;
}

That way you make minimal changes to the OOB workflow, and leave yourself open to running the default workflow if you set up a new site on the same instance, and don't want it subject to your custom workflow.

Answer 3

We've created a custom property in each page, "page owner", which in fact is a pointer to a group (I wish we have made it inheritable through the tree since beginning). Then workflow was customized so that page owner group receives this in their inbox for approval.