User tasks

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).

User task 1

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:

Edit User Task tab

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

Tasks app and tasks

Magnolia uses its Task Management module to implement jBPM User Tasks into the Tasks app. The app 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:

WorkItemHandler registry

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 Tasks app 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 Tasks app. 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 the Tasks app. 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:

Publish task definition

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


DX Core



This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules
6.3 beta

Magnolia 6.3 beta

Magnolia 6.3 is in beta. We are updating docs based on development and feedback. Consider the 6.3 docs currently in a state of progress and not final.

We are working on some 6.3-beta known issues during this phase.