Version 4

    These patterns are taken from the Workflow Patterns Initiative. For the status of currently supported patters, have a look at BPMSupportedPatterns


    Control-Flow Patterns


    Covers the Control-Flow Patterns defined by the Workflow Patterns Initiative.


    Basic Control Patterns


    This class of patterns captures elementary aspects of process control



    Advanced Branching and Synchronization Patterns


    A series of patterns which characterise more complex branching and merging concepts which arise in business processes.



    Multiple Instances Patterns


    Multiple instance patterns describe situations where there are multiple threads of execution active in a process model which relate to the same activity



    State-based patterns


    State-based patterns reflect situations for which solutions are most easily accomplished in process languages that support the notion of state.



    Cancellation Patterns


    Patterns that have variants that utilize the concept of activity cancellation where enabled or active activity instance are withdrawn. Various forms of exception handling in processes are also based on cancellation concepts.



    Iteration Patterns


    The following patterns deal with capturing repetitive behaviour in a workflow.



    Termination Patterns


    The following patterns deal with the circumstances under which a workflow is considered to be completed.



    Trigger Patterns


    The following patterns deal with the external signals that may be required to start certain tasks.



    Data Patterns


    Covers the Data Patterns defined by the Workflow Patterns Initiative.


    Data Visibility


    Within the context of a process, there are a variety of distinct ways in which data elements can be defined and utilized. Typically these variations relate to the process construct to which they are anchored and the scope in which they are accessible. More importantly, they directly influence the way in which the data element may be used, e.g. to capture production information, to manage control data or for communication with the external environment. Here we consider each of the potential contexts in which a data construct can be defined and utilized.



    Data Interaction


    Here we examine the various ways in which data elements can be passed between components in a process and how the characteristics of the individual components can influence the manner in which the trafficking of data elements occurs. Of particular interest is the distinction between the communication of data between components within a process as against the data-oriented interaction of a process element with the external environment.


    Internal Data Interaction



    External Data Interaction


    Data Transfer Patterns


    Here we consider the manner in which the actual transfer of data elements occurs between one process component and another. These patterns serve as an extension to those presented in the Data Interaction patterns and aim to capture the various mechanisms by which data elements can be passed across the interface of a process component.



    Data-based Routing


    Whereas the above sections have examined characteristics of data elements in isolation from other process perspectives (i.e. control, resource, etc.), the following patterns capture the various ways in which data elements can interact with other perspectives and influence the overall operation of a process instance.



    Resource Patterns


    Covers the Resource Patterns defined by the Workflow Patterns Initiative.


    Creation Patterns


    Creation Patterns correspond to limitations on the manner in which a work item may be executed. They are specified at design time, usually in relation to a task, and serve to restrict the range of resources that can undertake work items that correspond to the task. They also influence the manner in which a work item can be matched with a resource that is capable of undertaking it.



    Push Patterns


    Push Patterns characterise situations where newly created work items are proactively offered or allocated to resources by the system. These may occur indirectly by advertising work items to selected resources via a shared work list or directly with work items being allocated to specific resources. In both situations however, it is the system that takes the initiative and causes the distribution process to occur.





    Pull Patterns


    Pull Patterns correspond to the situation where individual resources are made aware of specific work items, that require execution, either via a direct offer from the system or indirectly through a shared work list. The commitment to undertake a specific task is initiated by the resource itself rather than the system. Generally this results in the work item being placed on the specific work list for the individual resource for later execution although in some cases, the resource may elect to commence execution on the work item immediately.



    Detour Patterns


    Detour Patterns refer to situations where work item distributions that have been made for resources are interrupted either by the system or at the instigation of the resource. As a consequence of this event, the normal sequence of state transitions for a work item is varied.



    Auto-Start Patterns


    Auto-start patterns relate to situations where execution of work items is triggered by specific events in the lifecycle of the work item or the related process definition. Such events may include the creation or allocation of the work item, completion of another instance of the same work item or a work item that immediately precedes the one in question.



    Visibility Patterns


    Visibility Patterns classify the various scopes in which work item availability and commitment are able to be viewed by resources. They give a indication of how open to scrutiny the operation of a PAIS is.



    Multiple Resource Patterns


    Up to this point, the focus of this catalogue of patterns has been on situations where there is a one-to-one correspondence between the resources and work items in a given allocation or execution. In other words, resources cannot work on different work items simultaneously and it is not possible that multiple resources work on the same work item. In situations where people are not restricted by information technology, there is often a many-to-many correspondence between the resources and work items in a given allocation or execution. Therefore, it may be desirable to support this using process technology. Here we discuss patterns relaxing the one-to-one correspondence between resources and work items that we have assumed previously.



    Exception Handling Patterns


    Covers the Exception Handling Patterns defined by the Workflow Patterns Initiative.


    At Work Item Level


    At Case Level


    Recovery Action