IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing business processes > Building human tasks

Human tasks

A human task is, quite simply, a unit of work that involves a human. Quite often, this task requires that the human interact with other services, and thus becomes a task within a larger business goal.

The IBM Integration Designer tools have been designed so that users can easily compose integrative business solutions without programming skills. To this end, you can easily define a human task in an intuitive graphical programming environment called the human task editor.

Before you start to use the human task editor, an example of a human task is described and some key concepts are presented:

Human tasks can only be deployed to IBM Process Server.


An example of a human task

Let us begin with an example of a human task. This graphic illustrates the steps involved when a staff member accepts a task.

In this example, this particular task is likely part of a much larger process which stops and waits until the staff member makes a decision.

Task Definition

A Task Definition is a representation of the task that includes the following:

  • who can do the task (roles/people assignment criteria)
  • what needs to be done (name)
  • what happens when the task takes too long (escalation)
  • how the task will be done (input and output data)

In the runtime environment, a task definition starts as a single work item. Over time, the task definition may generate multiple work items.


Assigning people to the task

When you create a human task an important step is to define which people can work on this task. You define who is eligible to perform the work using roles and people assignment criteria.

Roles

A role is a group of employees who share the same level of authority and access rights. When a task is assigned to a role, any staff member in that role group can complete the task.

People assignment criteria

These criteria define the members of each of the role groups.

You specify who can work on a task by assigning a role to the task and by ensuring that the membership of that role is set to the right group of people.

Often, tasks need only one person to do work in order to complete them, but some tasks will require input from multiple people. An example would be a purchase request which must be approved by three managers. You specify an ownership pattern to your human task which distinguishes between these cases. The supported ownership patterns are:

Single

The task requires only one owner. The first potential owner to claim the task does all the associated work.

Parallel

The task requires multiple owners. A subtask is created for every potential owner. Each of these people can work simultaneously on their assignment and when they are finished, criteria that you specify are used to aggregate the results and determine when the task is complete.


Presenting a task to a staff member

When a human task is started, the staff member interacts with the task through a user interface in a client environment.

If you take a look at the example again, you will see that you have already been exposed to a client, it just was not spelled out that way. Take a look at the example again with a few minor changes.

In this modified example, we see that all interaction between the user and the task is facilitated by a client. The task is delivered to the user through the client, and the resolution is returned in similar means.

So far, both examples have shown what happens when the task can be completed without a problem. What happens when that is not possible?


Escalations

An escalation is a course of action that is begun when an expected result from a task has not been achieved within a set period of time.

For example, let us look at the same scenario again, and see what happens when it is not properly completed.

In this example, we see that the staff member who claims the task isn't able to complete it in the specified period of time, and another staff member is alerted. Presumably, this second employee has the authority to investigate the reasons behind why the task wasn't completed and proceed accordingly.

There are three possible states for which an escalation can be configured:

Ready

When a human task is in a ready state, it is waiting to be claimed.

You can configure an escalation to trigger if it sits unclaimed for too long. This state does not apply to parallel ownership tasks.

Claimed

If a staff member has claimed a task, but takes longer than the specified period of time to complete it, an escalation is triggered and another staff member is notified. This state does not apply to parallel ownership tasks.

Subtask started

A subtask is an additional unit of work that is split out from a parent task. If the subtask fails to complete within a specified period of time, the parent task is escalated and indicates that it is still waiting on the subtask.

Running

For invocation tasks (those in which a person calls a service) the only applicable escalation state is Running (since such tasks are automatically claimed by the service). Actions can be defined if the service fails to complete its work in a specified time.


Collaborating with other staff members in a human task

Ad hoc tasks and transferred work items are created "on-the-fly" in the runtime environment, usually because the situation that has created the need for a task did not exist when the application was initially developed. You can create such tasks either from existing task definitions (collaboration and invocation tasks) or without any existing definition.

You can use IBM Integration Designer to create two types of ad hoc tasks: the subtask and the follow-on task. Definitions of these ad hoc tasks and transferred work items are given below.

Subtasks

In the runtime environment, if a person who claims a task finds that they are not able to complete it by themselves, they can delegate portions of that original task to other people in the form of subtasks.

Follow-on tasks

In the runtime environment, if a person who claims a task finds that they are not able to complete it, they can assign the remaining work to somebody else in the form of a follow-on task.

Transferred work items

In the runtime environment, if a person who claims a task finds that they are not able to complete it, they can transfer the work item to another person or group.


Single and parallel ownership of human tasks

When you create a human task you can choose between single and parallel ownership. A parallel ownership task (or simply a "parallel task") is one in which multiple people can work on a task at the same moment. Single ownership means that only one person can work on a task. The first potential owner to claim a task becomes solely responsible for that task.

You can use IBM Integration Designer to create single and parallel tasks, or to convert a task from one to the other. Definitions of these concepts are given below.

Single ownership tasks

A single ownership task can only be worked on by one person. A group of people may be eligible to claim the task as their own, but as soon as the first person claims the task it is no longer available to others.

Parallel ownership tasks

Subtasks are created for each potential owner of the task. Subtask owners work simultaneously and the results are aggregated when a sufficient number have completed their assignments. You can use propagation settings to allow the subtask owners to see the results of other owners, or to make individual responses secret.

You can change the ownership pattern on the Human Task editor.

Building human tasks