Magnolia 5.7 reached extended end of life on May 31, 2022. Support for this branch is limited, see End-of-life policy. Please note that to cover the extra maintenance effort, this EEoL period is a paid extension in the life of the branch. Customers who opt for the extended maintenance will need a new license key to run future versions of Magnolia 5.7. If you have any questions or to subscribe to the extended maintenance, please get in touch with your local contact at Magnolia.

What is a User task?

From the official jBPM documentation:

Processes can also involve tasks that need to be executed by human actors. A User Task represents an atomic task to be executed by a human actor. It should have one incoming connection and one outgoing connection. User Tasks can be used in combination with Swimlanes to assign multiple human tasks to similar actors. Refer to the chapter on human tasks for more details. A User Task is actually nothing more than a specific type of service node (of type "Human Task").

Compared to Custom tasks a User task expects some kind of human interaction. When modeling a User Task in your process you have an edit mask giving you more possibilities to set parameters tailored for user interactions:

You can also define swim lanes inside your process in context with Human Tasks. A swim lane allows you to define multiple steps or user tasks inside your process to be automatically assigned to the first user who picks up the first task of the swim lane.

Magnolia's implementation

Pulse and tasks

Magnolia uses its Task Management module to implement jBPM User Tasks into the Pulse. The Pulse gives the user a convenient overview of tasks and their current status.

See Tasks documentation for details.


From a technical point of view there is no difference between Custom tasks and User Tasks; both are handled by a WorkItemHandler registered at startup and both implement the same interface. The handler for Human Tasks is configured as follows, where the "Human Task" value in the name property is mandatory for the jBPM engine to pick it up as handler for Human Tasks:

If you don't use a Human Task, a user will not be informed about the workflow and they cannot interact with it. There will be no task in the Pulse for users to act on.

Human Task work item handler

What the handler does internally is:

  • Create a Task based on the parameters provided by the work item.
  • Create the Content based on parameters from the work item by using a parameter resolver. The content data is used for the user to make some sort of decision to complete the task and is usually displayed in the Pulse. The resulting data is then added to the result map of the task.
  • Add the task to the TasksManager.
  • Claim the task as part of a swim lane, otherwise an actor would have to manually claim it.

Parameter resolver

The jBPM engine only allows registering one Human Task Handler. But a human task can be anything involving human interaction. The only thing all human tasks have in common is that they contain some sort of data, a human user who might need to fulfill his task, and the resulting data. This data is the Content or respectively the Result map of a Task. To allow distinguishing between tasks, Magnolia is using TaskDefinitions and ParameterResolver configured inside the TaskDefinition Registry.

The Parameter Resolver takes care of creating the data used by a user to fulfill a task. This is usually the data displayed in Pulse. Where that data comes from is up to the implementer. It could for instance be read from the WorkItem Parameters associated with the Human Task inside the Process, so the fields from edit mask, or they may come from the task configuration itself or anything else.

As an example here is the definition of the publish task associated with publication:

The Content and Result Map can be any Map<String, Object> map where Object is a primitive Type.