A Workflow Implementation for Delegating the Approval Process in AEM

Adobe Experience Manager has the capability of hosting multiple websites on one instance. It has been engineered to be an enterprise-level content manager. As such, we had a client that wanted to leverage this by allowing multiple departments in their company to share the same AEM instance. A few challenges were presented as we sought to engineer a unique AEM experience for authors in each department.

One requirement that we needed to fill was to allow each department the capability to send its content through its own approval process. Each team had various stakeholders that were involved for approving and publishing their own web content. We needed to allow each department the capability to author its own unique approval workflow process for its authors to use and its stakeholders to participate in.

Approval workflows can easily be created out of the box with Adobe Experience Manager. Someone familiar with the default AEM workflow knows how to create a workflow model so that different user groups can be notified when content is pushed through the workflow. With the right AEM knowledge of workflows and the right permissions set for various users, this task can be accomplished without any development.

The real challenge came from the following requirement. Each author that did not have replication permissions needed to be able to click the Request for Publication button to trigger their team’s approval workflow. Currently OOB with AEM 6.0 if an author does not have replication permissions, the Activation button is replaced with a Request for Activation button. This button then triggers the Request for Activation workflow in Adobe Experience Manager.

In theory, you could create all the approval processes by adding all business logic into the OOB Request for Activation workflow. This would be dangerous since multiple authors would be editing the same workflow that would be used by different departments. The workflow could also become convoluted quickly since an indeterminate amount of departments would contribute to one workflow.

While Axis41 generally would prefer to use a centralized service configuration for multi-hosting configurations, we recognize that sometimes other constraints come into play, causing a project to be better suited for solving a smaller subset of the problem. To this end, for this particular project to develop the following solution:

We decided to overlay the Request for Activation workflow in AEM. We wanted to do this without completely changing the OOB functionality, so we created an “OR split” in the Request for Activation with the OOB workflow steps set to the default path.


We then created a checker that would validate if the requested content sent into the workflow was relevant to any of the projects. We decided to have the content path be the predicate for the content. If the content path of the payload matched a configured content path from one of the departments, then it was sent to the configured workflow model. If there was no match, then the default behavior would be the OOB Request for Approval process. If there was a match, then a Workflow delegation process would delegate the content to its configured workflow model. This workflow process is in an OSGi bundle that keeps track of all the configuration information for each department. This bundle also contained a service that encapsulated all the check logic and other workflow delegation business logic. This bundle can be downloaded below. An example of the usage of this bundle are below.

The OR split logic would use a service in this OSGi bundle like so:

//this function checks to see if the passed in payload has an activation workflow associated with it.
function check(){
        var checker = sling.getService(Packages.com.axis41.aempodcast.workflowdelegator.service.WorkflowModelTracker);
        return checker.isActivationPage(workflowData.getPayload().toString());
    } catch (e){
        log.error("Request for Activation checker fail.\n"+e);
        return false;

The OSGi bundle that process this logic and that can be configured can be downloaded here.

By doing this, we gave the capability to each department to create an approval workflow model independent from every other department while still enjoying the freedom of requesting publication for their content. The workflow delegation process would simply trigger the correct approval process based on the content passed in. We also gave the capability to allow Adobe Experience Manager to do its default Request for Activation functionality if a specific department did not have an approval process.

If you are interested in more workflow discussion then check out our article about customizing workflows in AEM by Adobe Certified Expert Curtis Mortensen. Or sign up to receive updates when we post a new article.