Workflow Nets (WF-Nets) are the notational basis for WoPeD. They are an extension of classical Petri Nets established by Wil van der Aalst (TU Eindhoven). A WF-Net is supposed to have a very regular structure: It must contain exactly one place with no incoming arcs (the input place) and exactly one place with no outgoing arcs (the output place). Moreover, the net graph (extended by one "virtual" transition with an arc from the output place and an arc to the input place) must be strongly connected, i. e. from each node there exists a directed path to any other node.

Four special transition types are added to express branching situations in a more compact way: AND-split, AND-join, XOR-split and XOR-join, each of them being associated with a graphical symbol. Conceptionally, these special transitions are nothing more than shortcuts ("syntactic sugar") for an underlying equivalent standard Petri Net, such that the formal nature and executability of the Petri net calculus is preserved.

Triggers are added to the standard Petri net notation in order to represent different kinds of dependency between a task of the workflow process and its operative environment. Four types of trigger are distinguished:

• Resource trigger
  Task execution depends on the availability of a certain human or machine instance (e. g. free agent in a call center)
• Message trigger
  Task execution has to wait for the arrival of an external signal or event (e. g. incoming email)
• Time trigger
  Task execution depends on a time-related event (e. g. midnight to send a fax)
• No trigger
  Task execution is independent from its environment and done automatically (e. g. sending a system-generated email notification)

WF-nets allow to assign exactly one trigger type to every transition. The trigger type is graphically represented by a small, self-explaining icon near the associated transition symbol.

A set of four basic routing primitives can be identified, using the previously defined special transitions as control flow elements:

• Sequential routing
  Task A is executed before Task B
• Alternative routing
  Either Task A or Task B is executed
• Parallel routing
  Task A and Task B are executed concurrently, i. e. in any order
• Iterative routing
  Task B is repeated

Moreover, several notations are added to associate workflow tasks to resources by assigning one or more resource classes to every resource-triggered transition. The classes must be defined and maintained in a separate resource model, consisting of groups and roles. Additionally, the following quantitative performance parameters are assigned to the elements of a WF-Net:

• Average number of cases per time unit (arrival rate)
• Average execution duration of a workflow task
• Branching probabilities of XOR-Splits

By associating a WF-net with a resource model in the described manner, the associated workflow process can be embedded into a testing environment, ready to be analyzed e. g. by quantitative methods like capacity planning or throughput measurements. The above figure shows a WF-net with all mentioned additional notations.

The most important property of WF-Nets is soundness, implying that the model is not only structurally well-formed (as covered by the definition of WF-Nets) but also behaviourally well-formed. This means that every maximal execution of the net which starts from the initial marking (= one token on the input place and no tokens elsewhere) eventually leads to the final marking (= one token on the output place and no tokens elsewhere) This implies that there are not deadlock situations except from the final marking (which is a "wanted" deadlock) and the net is bounded.

A subprocess concept is added to handle the graphical and logical complexity of large workflow process definitions by modularization. This allows workflow processes contain another WF-Net as a subprocess. The net notation is simply extended by another special transition symbol standing for one particular subprocess. Note that each subprocess must be a sound WF-Net itself in order to support this simple and flexible plug-in concept.