Workflow Overview

You are reading the AEM 5.6 version of Workflow Overview.
This documentation is also available for the following versions: CQ 5.5

AEM encompasses several applications that are designed to interact and complement each other. In particular, the Workflow engine can be used in tight conjunction with several of the other applications.

For example, a key application of AEM is Web Content Management (WCM), which enables you to generate and publish pages to your website. This functionality is often subject to organizational processes, including steps such as approval and sign-off by various participants. These processes can be represented as workflows, which in turn can be defined within AEM, then applied to the appropriate content pages.

Workflows are at the center of how form submissions in AEM are typically processed. When creating a new form, the form submission can be easily associated with a workflow model, for example to store the content in a particular location of the repository or to notify a user about the form submission and its content.

Many useful workflow models are provided as part of the default AEM installation. In addition, any number of custom workflow models, tailored to the specific needs of your project, can be defined using the Workflow console.

Workflow models consist of a series of steps. When a workflow is started, that new workflow instance, associated with its payload, for example the data that was submitted in a form, advances through these steps. Such workflows can pass through automated Process steps or manual Participant steps, and can follow rules (AND/OR splits and joins) as well as trigger Container sub workflows.

Workflows at Design and Run Time

Workflows enable you to automate processes for managing resources and publishing content in your AEM environment. Workflows are comprised of a series of steps, where each step accomplishes a discrete task. Logic and runtime data can be used to make decisions when a process can continue using one of multiple possible steps.

For example, business processes for creating and publishing web pages include approval and sign-off tasks by various participants. These processes can be modeled using AEM workflows and applied to specific content.

A workflow is made of steps. Automated steps, also called process steps, can be defined by using either an ECMA script or a service (a Java class in a bundle). Rules for OR split can be defined with ECMA scripts. Services can be developed to listen to special workflow events and perform tasks according to the business logic. The Java API, the main workflow objects and the REST API are described. The last section explains how to change the workflow specific log level to efficiently debug the code.

Model

Is made of WorkflowNodes and WorkflowTransitions. The transitions connect the nodes and define the "flow". The Model has always a start node and an end node.

Workflow models are versioned. Running Workflow Instances keep the initial workflow model version that is set when the workflow is started.

Step

There are different types of workflow steps:

Participant (User/Group): These types of steps generate a work item and assigns it to a user or group. A user must complete the work item to advance the workflow.
Process (Script, Java method call): This type of step is executed automatically by the system. An ECMA script or Java class implements the step.
Container (Sub Workflow): This step starts another workflow model.
OR Split/Join: Uses logic to decide which step to execute next in the workflow.
AND Split/Join: Executes multiple steps simultaneously.

All the steps share the following common properties: Autoadvance and Timeout alerts (scriptable).

Transition

Defines the link between two consecutive steps.

It is possible to apply rules.

WorkItem

Is the "there is a task identifier" and is put into the respective inbox.

A workflow instance can have one or many WorkItems at the same time (depending on the workflow model).

The WorkItem references the workflow instance.

In the repository the WorkItem is stored below the workflow instance.

Payload

References the resource that has to be advanced through a workflow.

The payload implementation references a resource in the repository (by either a path or an UUID) or a resource by a URL or by a serialized java object. Referencing a resource in the repository is very flexible and in conjunction with sling very productive: for example the referenced node could be rendered as a form.

Lifecycle

Is created when starting a new workflow (by choosing the respective workflow model and defining the payload) and ends when the end node is processed.

The following actions are possible on a workflow instance:

Terminate
Suspend
Resume
Restart

Completed and terminated instances are archived.

Inbox

Each logged in user has its own workflow inbox in which the assigned WorkItems are accessible.

The WorkItems are assigned either to the user itself or to the group to which he belongs.

About the Workflow Console

The Workflow console is the centralized location for workflow management in AEM. It can be accessed via the Workflows link on the AEM Welcome page (Classic UI), and the Tools section of the touch-optimized UI.

Note

The Welcome page also offers access to the Inbox, which lists workflows awaiting action and allows you to take action as required. Workflow related functionality is also made available elsewhere in AEM, such as drop-down menus, in dialog windows, and from Sidekick when editing a page.