WS-HumanTask defines human tasks, including their properties, behavior, and set of operations needed to manipulate them. Although WS-HumanTask is a sister specification to WS-BPEL4People and is expected to be widely used in conjunction with BPEL, it is designed to be a standalone specification, enabling invocation of tasks from any business process (BPEL or otherwise), as well as from any Web Services client. (Note that throughout this article, we use task as shorthand for WS-HumanTask task.)

BPEL4People uses BPEL's extension mechanisms to layer human interaction capabilities on top of BPEL. At the core of these extensions is People Activity, which enables a task to be invoked from a BPEL process. Other extensions bind people assignments to people directories, assign task properties, and manipulate tasks in BPEL processes.

Figure 1 shows the logical architecture of the BPEL4People specifications. A BPEL process invokes a People Activity (task). A WS-HumanTask engine manages the lifecycle of the task and provides interfaces to the client application for operating on the task. This separation of the process and the task engine allows both to be deployed, managed, and scaled independently. It also enables the use of a unified task engine working with multiple BPEL and other process engines, possibly from different vendors. WS-BPEL4People also enables inclusion of the task definition inline in the BPEL process.

People Roles
A key aspect of human interactions in a process is the definition of who is responsible for doing what. The BPEL4People specifications go beyond the notion of a task performer and include the following human roles:

• Actual owner: The actual owner of a task is the person doing the task. The actual owner can perform actions associated with the task as well as forward, suspend, and resume a task.Potential owners: The concept of potential owners is useful when multiple people - usually members of a named group - work on shared tasks. A potential owner becomes the actual owner by claiming the task.
• Excluded owners: When a task is assigned to a defined group of people, some users can be explicitly excluded from being a potential owner. This is particularly useful when having to ensure that the person reviewing a task is not the person performing it (the 4-eyes principle).
• Task initiator: A task initiator is the person initiating the task or the business process. The initiator can track the status of the task; collaboration with the initiator can also be needed to close the task.
• Task stakeholders and business administrators: Task stakeholders and business administrators are ultimately responsible for the oversight and the performance of the task. They can participate in the performance of the task, for example, by adding attachments or forwarding the tasks. They can also perform business administration functions such as suspending tasks or resolving missed deadlines. Task stakeholders are only assigned to a specific task instance; business administrators are assigned to all instances of a task type.
• Notification recipients: Anyone included on a notification list is classified as a notification recipient.

Assignments
To assign actual people to these various roles, the BPEL4People specifications support the static binding, late binding, and dynamic binding of people to roles. Assignments are made via:

• Literals: In its simplest form, people are literally assigned to roles using user identifier(s) and group name(s). This form of assignment is most common when tasks are assigned to named groups (or work queues).
• Logical people group: A logical people group represents a person or set of persons, or one or more named groups. A logical people group is bound to actual people and groups at deployment using a query, with zero or more query parameters, against a people/identity directory. This form of assignment is useful in scenarios such as skill-based assignment.
• Expressions: Expressions can be used in both a task definition and in the invoking BPEL process to assign people to roles. This form of assignment is most common when an assignment depends on the actual performer of a previous task, as when implementing the 4-eyes principle.

Delegation and Nomination
BPEL4People specifications support the assignment of task instances at runtime, particularly two common workflow patterns: delegation and nomination.

The BPEL4People specifications enable the definition of constraints on delegation. A task definition can specify that it can be delegated to anyone, to only potential owners as determined by assignment, to a specific set of people or named groups, or to no one. By default, tasks can be delegated to anyone.

As mentioned earlier, task stakeholders can assign task instances at runtime. This, in conjunction with the fact that a task can be created without an owner being assigned, enables a pattern commonly known as nomination in which business users overseeing the process nominate users to perform a task on an instance-by-instance basis.

Notifications
Notifications inform people of noteworthy events, call their attention to an action they need to take, or advise them of a change in status. The BPEL4People specifications treat notifications as a special case of human tasks; most of the task discussions in this article also apply to notifications. There are a few differences between notifications and tasks, for example, notifications are essentially one-way - the progress of the caller isn't blocked for the notification the way it is for a task. Notifications can be sent to multiple recipients and can be managed by one or many business administrators; the other roles do not apply to notifications. Notifications also don't have attachments, comments, or deadlines (these concepts, as applied to tasks, are discussed later in this article).

Timeouts and Escalations
A key benefit and requirement of managing human activities using a process or task engine is the ability to manage the timely performance of tasks and associated escalations.

The BPEL4People specifications allow multiple deadlines to be associated with a task. These deadlines can be start deadlines or completion deadlines. Both deadlines can be specified as a duration (period of time), or a deadline (point in time), and are calculated from the time the task is created. Expressions can be used to compute the deadlines at runtime, enabling both context-based deadlines (for example, deadlines based on order amounts or a customer's premium status) and the integration of a business calendar (for example, to compute the number of calendar days that correspond to three working days).

One or more escalations, with associated conditions, can be associated with a deadline. An escalation is triggered if the point of time specified as a deadline has been reached or the duration has elapsed, and the associated condition evaluates to true. Escalations can use notifications to inform people of the status of the task or reassign the task to different users or groups.

Deadlines and escalations are illustrated in Figure 2.

Task Lifecycle
To understand these task concepts as a complete picture, it helps to visualize the various task states and transitions. Figure 3 shows a simplified view of a task's lifecycle.

All tasks start in the Created state. A task remains in the Created state until it is activated (if scheduled activation is used) and has potential owners. If there are no potential owners, the task remains in the Created state until the business owner has performed nomination.

Once activated, a task moves into the Ready state if it has multiple potential owners (for example, when it is assigned to a group or a queue) or into the Reserved state if there is only a single potential owner. Tasks in the Ready state move into the Reserved state when one of the potential owners claims it.