Workflow enables business process management in Experience Manager, and is used for automatic processing of content and well as facilitating governance and process requiring human decision making. Workflow is defined via Workflow Models that are composed of a series of steps and created and managed in the Workflow Model Editor.
Let’s take a look at AEM’s Workflow Model Editor. Workflows are AEM’s method for applying business processes in AEM, and workflow models are the definition of the work to be done. Workflows can be broken into two main categories. The first is programmatic workflow which is applied to content in AEM and processed based on some business rules. The canonical example of this is AEM’s out-of-the-box DAM Update Asset workflow which is automatically invoked upon asset upload and processes assets to generate renditions and apply smart tags. The second category of workflow is driven by human interaction and takes content through business processes shepherded by one or more human actors. A common example is a content review workflow which engages a series of AEM users requiring them to review content before publication. When a workflow instance is created, it’s really just a workflow model being applied against some content in AEM, and this content is called the workflow’s payload and is typically a page, asset, or experience fragment. Let’s dive into the definition of a workflow model. For this, we’ll take a look at the publish example workflow model provided by AEM. In the Workflow Model Editor, we’re greeted with a series of workflow steps that represent the work to be done by the workflow model. In our example, the first step, the Validate Content step, assigns a workflow instance to an AEM user to review the workflow’s payload. The second step, Publish Content, replicates a content to an AEM Publish instance. As we dig a little further in edit mode, we first review the workflow model properties which are a set of configurations for the workflow model in its entirety. The title is what’s displayed to AEM users when selecting the workflow, so it’s important to give it a meaningful name. Tags indicate which consoles in AEM the workflow model is available for. In this case, we have the WCM tag so this is only intended for use in the site admin. The two check boxes at the bottom are of particular note. Enabling Transient Workflow acts as a performance booster for the workflow’s execution as it removes the overhead of generating and maintaining workflow history. Typically transient workflow is used for the programmatic executions where workflow history is not required and there is little to no human interaction of substance. Our workflow is managing the business process of content review, so it makes sense that we would want to maintain a workflow history of when and by whom content was approved for publication. We will leave this unchecked. Multi Resource Support allows multiple pieces of content to be bundled together and put under the same workflow. If this is unchecked and multiple pieces of content are selected for the workflow, a discreet workflow instance will be created for each piece of content. This is typically left checked since when users select multiple pieces of content and apply the workflow to them, the assumption is that the content will go through the workflow together. For our example, it makes sense that we want to bundle the multiple pages for review at once, so we will keep this checked. Let’s jump over to the Stages tab. Stages are rather interesting as they allow us to define key points in the workflow’s lifecycle and expose them to AEM users interacting with the workflow to help them understand where they are in the overall workflow itself. Let’s add three logical steps for our example, Marketing Review, Legal Review, and Content Publication.
Let’s look at the workflow model step definition. After selecting a step, we can click the wrench to configure it. Let’s update this step to be our marketing review.
In the Workflow Stages dropdown, we will have a list of all the workflow stages that we defined in the workflow model properties. We’ll select Marketing Review. We can also set the user group to assign the step to. And for this, we can set it to an AEM user group named Marketing.
Let’s do something a bit more interesting and add a conditional legal review step. For this, we can add an OR split which will let the marketing reviewer send the email to either legal review or straight to publication. Let’s add a new participant step for legal review to the left branch and configure it in a similar fashion to our first review step. Keep in mind that the workflow step titles are displayed to AEM users interacting with the workflow, so it’s important to make sure that they are semantic and clear. Remember that workflow stages are intended to help conceptualize the workflow and its life cycle. These don’t have to be applied to every single step, but rather only to key steps in the workflow’s life cycle. Lastly, let’s not forget to add our final workflow stage to the Publish Content step. After making changes to the workflow model, these changes must be synced into AEM’s workflow engine. This can be done by clicking the Sync button in the upper right corner. Our sync has failed. This is because AEM is smart and validates a workflow model prior to syncing to ensure the model is valid and properly configured. In this case, we forgot to add a step to the OR split for when legal review is not required. Since we want this branch to automatically flow down into the Publish Content workflow step below, we can add a No Operation step and give it a title indicating that no legal review is required.
If we sync again, the model validates and is successfully synced into the AEM workflow engine and is ready for execution.
Now that we’ve updated our workflow model, let’s try it out. To do this, let’s run our publish example workflow on an AEM page to see what the experience is like. Keep in mind that I’ve added the admin user to both the marketing and legal review groups in AEM for this demo to avoid having to log in and out as different users. Let’s first select a page and add it to our workflow.
Since the first step is marketing review, the marketing reviewers receive an inbox notification. From here, the workflow’s task be open and inspected.
If we jump over to the Workflow Info tab, it lists the stages we defined in our workflow model properties and shows us where we are within the workflow’s lifecycle. Clicking View Payload, we see options to view the workflow steps in context.
After the marketing review, we added an OR split. Because of this, we have to select if a legal review is needed or not. Notice that the drop-down options are driven by the titles of the workflow steps in the branch. let’s require a legal review for this page.
Just like our marketing reviewers, the legal reviewers will receive a notification in their inbox. Legal can review the payload and send it back to marketing if needed, or they can approve for publication. Let’s approve, and now the page will be published.
Because our workflow model is non-transient, we’re able to review the workflow history under AEM, Tools, Workflow Archive. -