Pattern 7 (Retain Familiar)

FLASH animation of Retain Familiar pattern


Where several resources are available to undertake a work item, the ability to allocate a work item within a given case to the same resource that undertook a preceding work item.


  • If there are several suitable resources available to undertake the Prepare Match Report work item, it should be allocated to the same resource that undertook the Umpire Match task in a given workflow case.


Distributing a work item to the same resource that undertook a previous work item is a common means of expediting a case. As the resource is already aware of the details of the case, it saves familiarization time at the commencement of the work item. Where the two work items are sequential, it also offers the opportunity for minimizing switching time as the resource can commence the latter work item immediately on completion of the former.

This pattern is a more flexible version of the Case Handling pattern discussed earlier. It only comes into effect when there are multiple resources available to undertake a given work item and where this occurs, it favours the allocation of the work item to the resource that undertook a previous work item in the case. Unlike the Case Handling pattern (which operates at case level), this pattern applies at the work item level and comes into play when a work item is being distributed to a resource.

The Chained Execution pattern is related this pattern and is designed to expedite the completion of a case by automatically starting subsequent work items once the preceding work item is complete.


The Retain Familiar pattern takes the form of a one-one relationship between a task and a preceding task in the same process. Where it holds for a task, when an instance of the task is created in a given case, it is distributed to one of the nominated resources the completed one of the preceding tasks in the same case. If the preceding task has been executed more than once, it is distributed to one of the resources that completed it previously.


There are no specific context conditions associated with this pattern.


Not surprisingly, this pattern enjoys wider support than the Case Handling Pattern. WebSphere MQ allows individual work items to be allocated to the same resource that started another work item in a case or to the resource that started the case itself. FLOWer provides a facility in the design time workflow model to enforce that a task must be executed by the same resource as another specified task in the case. COSA does the same thing using a customised distribution algorithm for a specific work item that requires it to have the same executor as another work item in the case. Similarly iPlanet achieves the same result using the linked user concept which requires two work items to be executed by the same resource. Oracle BPEL supports the pattern via the ora:getPreviousTaskApprover() function.


None identified.



Evaluation Criteria

An offering achieves full support if it satisfies the description for the pattern.

Product Evaluation

To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.





Staffware 9 - Not supported
Websphere MQ Workflow 3.4 + Common resource allocation can be specified for specific tasks in the process model requiring the same resource allocation at runtime within a case
FLOWer 3.0 + Directly supported at plan element level
COSA 4 + Supported via a customised distribution algorithm
iPlanet 3.1 + Directly supported through linked tasks with common resources
BPMN 1.0 - Not supported
UML 2.0 - Not supported
Oracle BPEL 10.1.2 + Oracle BPEL PM supports this pattern by means of the ora:getPreviousTaskApprover() function during the dynamic assignment an assignee to a task
jBPM 3.1.4 + jBPM supports this pattern through <assignment expression "previous"> for a task.
OpenWFE 1.7.3 - OpenWFE does not support this pattern.
Enhydra Shark 2 - Enhydra Shark does not support this pattern. Theatrically, the extended attribute "AssignToPerformerOfActivity" (together with some engine configuration) should give the possibility to specify that the performer of an activity shall be assigned a subsequent activity. In practice, we did not achieve the desired behaviour.

Summary of Evaluation

+ Rating

+/- Rating

  1. The process model provides support for specifying that the resource to which a work item is allocated should be the same as that to which a preceding work item was allocated within a given case
  1. N/A