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

Ownership patterns

When you assign potential owners to a human task you can establish a pattern of ownership. This pattern defines whether users can simultaneously interact with the task. Depending on the ownership pattern, you can also define completion conditions, propagation of user roles and aggregation options.

When defining potential owners for a to-do task or collaboration task you can choose from certain patterns of ownership:

Single

The first potential owner to claim the task becomes the tasks sole owner. The task is closed to all other potential owners. This would be a common choice in situations where a group of workers could claim a one-person task.

For example, a call is received by a telephone call center, all of the phone staff are eligible to claim the task, as soon as one member of staff claims the call it is no longer able to be claimed by anyone else.

Parallel

All potential owners can claim the task and work on it simultaneously. An example of when to use parallel ownership would be in a voting situation. The task will be assigned in parallel to all voters and each one can place their vote without waiting for their predecessor. The results of the vote can be combined using the aggregation options.

The following people assignment criteria cannot be used for the Potential Owners of parallel ownership tasks: Everybody, Nobody and Group. Choosing these people assignments for the Potential Owner role will lead to validation errors during deployment.

Ownership patterns do not apply to invocation tasks.

One consequence of the choice of single or parallel ownership is in the handling of escalations. For single ownership you can define escalations that are triggered when the task is in the ready or claimed state. Such escalations are not applicable to a parallel ownership task.

If you change the ownership of a task from single to parallel, you will be prompted for what to do with escalations that you have defined for the ready or claimed states. You can use them in a modified form, or you can delete them. If you choose to use them, they will be modified according to the following rules:

Mapping of escalations when switching from single to parallel ownership.
Single ownership Parallel ownership
Start state End state Start state End state
Ready Claimed Subtask started Ended
Ready Ended Subtask started Ended
Claimed Ended Subtask started Ended
Any subtask started state escalations will be used without modification, regardless of your choice.

The escalation retains no memory of its original state. If you convert a parallel task to single ownership, all escalations will remain assigned to the Subtask started state, regardless of their history.

Use the completion and aggregation options to indicate when a task can be considered complete and, in the case of parallel ownership, how the responses of the owners should be combined. In the Properties view of the People Assignment > Potential owners, there are tabs for Completion, Aggregation, and Propagation.

Completion

The completion settings allow you to define an early completion condition. You may need only a subset of the potential owners to complete the task before the BPEL process can proceed.

For example, you need two managers to sign off on a purchase request. When any two potential owners have responded the remaining user tasks are redundant and the task can be completed. The completion condition can be related to a deadline, the number of people who have worked on the task or on the results of the subtasks from individual owners.

Aggregation

The aggregation settings allow you to control the way in which individual responses are aggregated together into a single task result. In some instances you might prefer the response of the majority of respondents to carry the day, in other cases unanimity will be required. Aggregation conditions must be set for parallel ownership.

Propagation

When your human task is set to parallel ownership, individual user tasks are created as subtasks to the original task. The subtasks will adopt the default user roles of any human task. If you have specified non-default user roles for the main task you might want these roles to be propagated to the subtasks. In the Properties view of the People Assignment > Potential owners there is a tab for Propagation. Use the settings on the Propagation tab to define how user roles are propagated to the subtasks. In the People assignment to propagate field, select one of the following options:

None

None of the user roles will be propagated and the subtasks will use only the default user roles.

Administrator

Only the Administrator role will be propagated from the calling task to the subtasks. The propagation does not overwrite the default user roles of the subtasks. Instead the default roles and the propagated administrator roles will be combined. The subtasks will use the default user roles for other roles. This means that each subtask will have only one potential owner and no readers. Consequently, subtask owners will not be able to see the results of the other subtasks.

All

All user roles are propagated from the calling task to the subtasks. The propagation does not overwrite the default user roles of the subtask. Instead each of the default roles and its corresponding propagated role will be combined. All potential owners of the main task become readers of all the subtasks. Consequently subtask owners can see the results from all the other subtasks.

Defining the people assignment criteria


Related concepts:
Escalations


Related tasks:
Assigning roles to your human task