The Workflow Management Coalition Specification
The Workflow Management Coalition Specification
Workflow Management Coalition
Terminology & Glossary
Document Number WFMC-TC-1011
Document Status - Issue 2.0
June 96
Send comments to wmc_wgrm@ossi.com
Workflow Management Coalition
Avenue Marcel Thiry 204
1200 Brussels
Belgium
Tel: (+32 2) 774 9633
Fax: (+32 2) 774 9690
Email: 100113.1555@compuserve.com
The Workflow Management Coalition is a non profit organisation with the objectives of advancing the opportunities for the exploitation of workflow technology through the development of common terminology and standards. It has been recognised that all work flow management products have some common characteristics, enabling them potentially to achieve a level of interoperability through the use of common standards for various functions.
The WFM Coalition has been established to identify these functional areas and develop appropriate specifications for implementation in workflow products. Such specifications will enable interoperability between heterogeneous workflow products and improved integration of workflow applications with other IT services such as electronic mail and document management, thereby improving the opportunities for the effective use of workflow technology within the IT market, to the benefit of both vendors and users of such technology.
1.2.
Purpose
This document contains technical definitions for terms used in the workflow
management coalition specifications and discussions. The definitions
themselves will help in establishing a consistency in the use of terminology
across the industry.
1.3.
Scope
This document identifies the terminology used to describe the concepts and
general structure of a workflow management system, its major functional
components and their interfaces. It also provides a list of synonyms variously
used within the industry as alternative terms to the preferred WfMC terminology
It may be read in conjunction with the Workflow Reference Model, which
describes the architecture used by the WfMC within its standardisation
programme.
1.4.
Cross References
WfMC-TC-1003 Workflow Reference Model
WfMC-TC-1009 Workflow Client Application APIs (WAPI)
WfMC-TC-1012 Workflow Interoperability Specifications
WfMC-TC-1013 WAPI - Naming Conventions
WfMC-TC-1015 Workflow Audit Data Specifications
WfMC-TC-1016 Workflow Process Definition Interchange
1.5.
Revision History
This issue (2.0) is a significant update of version 1, incorporating:
* standard background material describing the WfMC
* the standard WfMC document structure
* revised terminology in some areas to improve clarity
* new terminology in various areas
* an index of terms and cross references
2
- BASIC CONCEPTS
This section identifies basic concepts and terminology associated with workflow as a general topic.
Workflow
Glossary - Relationships
between basic terminology
Figure 1.0 Relationships between basic terminology
* Many individual process instances may be operational during process enactment, each associated with a specific set of data relevant to that individual process instance (or workflow "Case")
* A loose distinction is sometimes drawn between production workflow, in which most of the procedural rules are defined in advance, and ad-hoc workflow, in which the procedural rules may be modified or created during the operation of the process.
* Workflow Computing
* Case Management
* Such systems also typically provide administrative and supervisory functions, for example to allow work reassignment or escalation, plus audit and management information on the system overall or relating to individual process instances.
[ The WfMC have published an architectural Reference Model, describing the structure and interfaces of a Workflow Management System..
* Workflow Manager
* Workflow Computing System
* Case Management
[ A business process has defined conditions triggering its initiation in each new instance (e.g. the arrival of a claim) and defined outputs at its completion.
* A business process may involve formal or relatively informal interactions between participants; its duration may also vary widely.
* A business process may consist of automated activities, capable of workflow management, and/or manual activities, which lie outside the scope of workflow management.
See also: Process, Process Definition
* The process definition may contain references to sub-processes, separately defined, which make up part of the overall process definition
* The WfMC Reference Model includes an interface for the import and export of Process Definitions
* Model Definition
* Routing Definition
* Flow Diagram
* State Transition Diagram
* Flow Schematic
* Workflow Script
* Instruction Sheet Definition
* An activity is typically the smallest unit of work which is scheduled by a workflow engine during process enactment (e.g. using transition and pre/post-conditions), although one activity may result in several work items being assigned (to a workflow participant)
* Wholly manual activities may form part of a business process and be included within its associated process definition, but do not form part of the automated workflow resulting from the computer supported execution of the process.
* An activity may therefore be categorised as "manual", or "automated". Within this document, which is written principally in the context of workflow management, the term is normally used to refer to an automated activity.
* Node
* Task
* Work Element
* Process Element
* Operation
* Instruction
(Each may be further described as a manual .... , or as an automated or
workflow ....)
Automated
Activity
* an invoked application being activated directly by the workflow management system (with no workflow participant being involved)
* one or more work items being assigned to a workflow participant, with supporting tools or applications being invoked and managed by the workflow management system
* one or more work items being assigned for a workflow participant to process independently of the workflow management system, with the completion of the workitems being notified to the workflow management system by the workflow participant (within a workflow system these may sometimes be described as manually executed work items)
For other aspects of usage see Activity
* Activity (colloquial)
Manual
Activity
* Manual Step
* Human Task
* Manual Work
Instance
(as in Process or Activity Instance)
* Each process instance represents one individual enactment of the process, using its own process instance data, and which is (normally) capable of independent control and audit as it progresses towards completion or termination. It represents the unit of work with respect to a business process which passes through a workflow management system (for example, the processing of one insurance claim, or the production of one engineering design).
* Each process instance exhibits internal state, which represents its progress towards completion and its status with respect to its constituent activities. (See Process State)
(Some business processes may never "complete" within a defined timescale in the accepted sense of the word, but achieve a protracted, persistent dormant state, which may require the process instance to be placed in an archive state, for example to support legal requirements on the maintenance of process data.)
* Case
* Workflow Definition Instance
* Instruction Sheet Instance
* Each activity instance represents a single invocation of an activity, relates to exactly one process instance and uses the process instance data associated with the process instance. Several activity instances may be associated with one process instance, where parallel activities exist within the process, but one activity instance cannot be associated with more than one process instance.
* Each activity instance is normally capable of independent control and audit and exhibits internal state. (See Activity State)
* Node Instance
* Task Instance
* Work Element Instance
Workflow
Participant
* (Where an activity requires no human resource and is handled automatically by a computer application, the normal terminology for the machine based resource is Invoked Application.)
* A workflow participant may be identified directly within the business process definition, or (more normally) is identified by reference within the process definition to a role, which can then be filled by one or more of the resources available to the workflow system to operate in that role during process enactment.
* Agent
* Player
* User
* Role Player
* An activity typically generates one or more work items which together constitute the task to be undertaken by the user (a workflow participant) within this activity
(In certain cases an activity may be completely handled by an invoked application which can operate without a workflow participant, in which case there may be no work item assignment.)
* The work item(s) are normally presented to the user via a work list, which maintains details of the work items allocated to a user, and a worklist handler, which interacts with the worklist on the behalf of the user
* The control and progression of work items rests with the worklist handler and the user, rather than the workflow engine, which is notified of workitem status (e.g. completion) via the worklist handler interface. (The WfMC WAPI interface includes standard API calls for this purpose.)
* Tools or applications may be invoked to support the processing of a work item, or it may be processed independently by a workflow participant, with the workflow management system merely notified of the completion of particular work items
* Work Object
* Work Queue Item
* Element
* Work Pool Item
* In some workflow management systems workitems may be placed in the worklist by a workflow engine for subsequently access and actioning by the worklist handler.
* In-Tray
* To-Do List
* Possible functions that may be performed by the worklist handler include:
* Selecting a work item
* Reassigning a work item
* Notifying completion of a work item.
* Invocation of a tool or client application as part of the work item processing
* The WfMC WAPI interface includes standard API calls for worklist handler communication with a workflow engine.
*
*
* WFM Application
* Workflow To-Do List Application
* Task Manager
* Active Work Performer
Workflow
Glossary - Overview of Processes and Worklist Structures
Figure 2.0 Showing relationships between key terminology
* The import and export of process definitions
* Interaction with client applications and worklist handler software
* The invocation of software tools or applications
* Interoperability between different workflow management systems
* Administration and monitoring functions
Figure 4 - The Workflow Reference Model
* A range of API calls to support functions between a workflow engine and applications or other system components
* Interchange formats and protocols to support interoperability between different workflow engines
* Formats for the exchange of information such as process definitions and audit data between a workflow engine and other external repositories.
* Workflow Management System API's
3-
PROCESS CONCEPTS & STRUCTURE
This section includes terminology used within the process definition and during process execution to describe the nature of the process flow and its interactions.
[ modified at a later date, or
[ modified during run time (usually under conditions of privilege or according to a particular user role).
* Business Process Modelling
* Directed Graph
* Petri Net
* Model
* Instruction Sheet
* A sub-process will have its own process definition
* The WfMC Interoperability scenarios identify various ways in which sub-processes may interact during workflow execution (e.g. nested sub-process, chained)
* Sub Workflow
* The deadline may be expressed as an attribute of the process definition or within workflow relevant data.
* Escalation procedures may be invoked if deadlines are not meant.
Once the form filling activity is complete the three sections of form X, sections A, B and C, are processed in parallel by the corresponding activities, Process Section A activity, Process Section B activity and Process Section C activity.
* Concurrent Processing
A purchase order is processed in three consecutive activities.
* Rendezvous
* Synchronisation join
* Conditional Routing
* Switch
* [[Alpha]]synchronous join
* While Loop
* Activity Block
* The pre-condition may refer to workflow relevant data within the expression and may also test system variables such as date or time. . It may also refer to an external event of some kind.
* The pre-conditions are defined within the process definition
* Activity start rules
* The post-condition may refer to workflow relevant data within the expression and may also test system variables such as date or time. It may also refer to an external event of some kind.
* The post-conditions are defined within the process definition
* The navigation rule may refer to workflow relevant data within the expression and may also test system variables such as date or time.
* Navigation rules are defined within the process definition
* Navigation rules identify the flow relationship between activities and are used to effect the desired sequence of activity execution, which may include parallel or sequential execution conditions.
(Note - Some workflow management systems may not define explicit transition conditions but use a combination of pre- and post-conditions to achieve an equivalent effect.)
* Navigation Rule
* Routing condition
* Process Rule
* Transition Rule
* Business Process Rule
* Conditional Routing
4
- WIDER WORKFLOW CONCEPTS & TERMINOLOGY
This section includes terminology used within the wider context of workflow management systems.
Workflow
Glossary - Generic Workflow Product Structure
* Client Applications, which request facilities and services from a workflow engine
* Invoked Applications, which support the processing of particular activities, or work items, and are initiated by the workflow management system
* Invoked Application
* Tool
* worklist handling
* process instance initiation and other control functions (e.g. suspend/resume)
* retrieval and manipulation of process definition data
* various system administration functions (for example suspending the use of certain process definitions)
* The Workflow Reference Model includes an interface for client application interaction which supports APIs for a variety of the above functions.
* Front-End Application
* Client Program
* The application may be invoked directly by the workflow management system or may be invoked indirectly via an application agent (or "tool agent"). The application agent provides a general mechanism for application invocation independently from any native workflow management system facilities
* The Workflow Reference Model includes an interface for application invocation functions.
* Work Performer
* Application (colloquial)
Workflow
Glossary - Overview of Workflow Data Structures
Figure 3.0 Types of Data in Workflow Management Systems:
* Workflow relevant data may be made available to a subsequent activity or another process instance and thus may affect the choice of the next activity to be chosen (for example decision data and/or reference values to be passed between activities)
* Data may be of two broad types
* Typed - the structure of the data is implied by its type (typically a workflow management system will understand the structure of such data and may be able to process it)
* Untyped - the workflow management system will not understand the data structure, but may pass the data (or a reference to the data) to workflow applications
* Case data
* Workflow control data examples include:
* state information about each workflow instance
* state information about each activity instance (active or inactive)
* information on recovery and restart points within each process
* etc..
*
* The workflow control data may be written to persistent storage periodically to facilitate restart and recovery of the system after failure. It may also be used to derive audit data.
* Workflow engine state data
* Workflow enactment service state data
* As the execution of a process instance proceeds it follows a series of transitions between the various states which it may take. The complete set of process states for a process definition fully defines the internal behavior which its process instances may follow.
* The WfMC Reference Model identifies a number of common states which a process instance may take:
* Initiated - the process instance has been created, but may not yet be running
* Running - the process instance has started execution and one or more of its activities may be started
* Active - one or more activities are started and activity instances exist (Further sub-states may be supported by particular implementations to record more detailed information about active activities.)
* Suspended - the process instance is quiescent; no further activities are started until it is resumed
* Complete - the process instance has achieved its completion conditions and any post-completion system activities such as audit logging are in progress.
* Terminated - the execution of the process has been stopped (abnormally) due to error or user request.
* Archived - the process instance has been placed in an indefinite archive state (but may be retrieved for process resumption - typically supported only for long-lived processes).
* The WAPI interface defines a number of calls to manipulate process state information, for example to interrogate process state or force a transition to a new state
* Model state
* The WfMC Reference Model identifies a number of common states which an activity instance may take:
* Inactive - the activity instance has been created, but may not yet been activated; no work item exists for that activity
* Active - one or more work items have been created and assigned for processing
* Suspended - the activity instance is quiescent; no further work items are started until it is resumed. (Note that some activities may not be suspendable.)
* Completed - the process instance has achieved its completion conditions and any post-completion system activities such as audit logging are in progress.
* Step state
* Case History
* History Repository
* Run Time Operation
* Workflow Execution (strictly this refers only to the automated parts of process execution)
* Examples of an organisational role are:
* Supervisor role
* Insurance Underwriter role
* Etc
* A workflow participant assumes a role given that he or she has the appropriate skill set.
* User Groups
* Organisational Groups
Organizational
Model
* Organisational Directory
* The role defines the context in which the user participates in a particular process or activity. The role often embraces organisational concepts such as structure and relationships, responsibility or authority, but may also refer to other attributes such as skill, location, value data, time or date, etc.
* Activity Group
* Workflow Performer Definition
* time based (see deadline)
* resource based (e.g. consumes less than ...)
* cost based (e.g. costs more than ...)
*
* Interpretation of the process definition.
* Creation of process instances and management of their execution, including start / stop / suspend /resume, etc.
* Navigation between activities and the creation of appropriate work items for their processing
* Supervisory and management functions
* etc
* The workflow engine normally excludes functions such as worklist handling, which are user centred, although these may share a common platform with the engine software.
* One or more workflow engines make up a workflow domain; which provides an homogeneous process execution environment. A workflow enactment service provides support for the execution of specific workflows over one or more workflow engines, which may be in one or more separate domains.
* Two or more workflow engines may co-operate to share the execution of workflows. See workflow interoperability
* Workflow Management Engine
* Case Processor
* The ability to make two or more workflow engines appear to provide a single workflow enactment service, with process execution shared between engines.
* Several different interoperability scenarios exist, describing alternative ways in which the execution of a process instance is shared between workflow engines.
* Hierarchic (Nested Subprocess)
* Connected Discrete (Chained)
* Connected Indiscrete (Peer-to-Peer)
* Parallel Synchronised
Further details can be found in the WfMC Workflow Reference Model and Interoperability specifications.
* The ability to interoperate between both homogeneous and heterogeneous workflow engines; possibly with different levels of functional capability.
* The Workflow Reference Model includes a functional interface (Interface 4) to support interoperability between (heterogeneous) workflow engines.
* A workflow enactment service may operate within a single (homogeneous) workflow domain, or using the facilities provided within the WfMC interoperability interface enactment may occur across engines within several (heterogeneous) domains.
* common workflow naming (processes/activities)
* common user naming
* common interpretation of process definitions and state transitions
* a common organisational model and roles
* a common supervisory interface
* common audit data
* etc
* Typically a workflow domain is built from a common, homogeneous product set.
* The Workflow Reference Model identifies an interface (4) to enable workflow interoperability between workflow engines, such that an enactment service for particular processes can span more than one domain, and incorporate heterogeneous products.
* Set up and management of user names, passwords and roles
* Assignment or re-assignment of work items
* Processing exception conditions
* Control of process definitions or versions thereof
* Monitoring of work or process instance progress
* System audit functions
* etc
* Administrators may make use of specialised administrative tools.
