#### Linking subtasks to form workflows

You can link the subtasks of a main task (and also the tasks of project or phase) to form a workflow by means of shared data or status conditions. Given two subtasks S1 and S2, you can make the following specifications concerning their input and output data:

o For subtask S2, you specify as input data a document D, which belongs to the output data of S1. Thus, S2 can only start, after S1 has been finished and document D has been released. There is a delivery relation between the two subtasks: S1 delivers D to S2.

o Likewise you could specify as output data of S1 the document D that belongs to the input data of S2. The effect is the same; the difference in procedure depends on which subtask is created first, S1 or S2.

You can also link subtasks to the main task by, e.g., taking over input data of the main task as input data of a subtask or by declaring the output data of a subtask as part of the output data of the main task. This way, work on the main task may be completely or partly distributed to subtasks.

If you specify, e.g., an input data field of a subtask as an input data field of the main task, then subtask and main task share this data field. Tasks that share a data field also share the value when it is released. This has the consequence that the value of the data field is copied from main task to subtask when value is released, in our example of an input field when the main task is started. The value of the data field cannot be changed in the subtask independently of the main task.

You can link subtasks not only via concrete data fields, but also via preconditions on the progress status of a subtask which is characterized by the release status of its input and output data:

o <input released>: The input data of a task are released by a task action, e.g. request, of the requestor: the requestor declares the input data as valid and may not change them now. The task is in state requested, committed, possibly already finished, but not, e.g., in state initial, request withdrawn or cancelled. As condition for the start of another task <input of S1 released> has the effect that the other task can start whenever S1 changes into a state where its input data are released.

o <output released>: The output data of a task are released by a task action (finish or complete) of the contractor: the contractor declares the output data as valid and may not change them now. The task is in state finished, accepted or completed, but not, e.g., in state requested or committed. As condition for the start of another task <output of S1 released> has the effect that the other task can start whenever S1 changes into a state where its output data are released.

If you want to have a subtask S2 only started after the subtask S1 has been finished, select the condition <output of S1 released> as input data of S2. If a main task should be only finished when its subtask S2 has been finished, select the condition <output of S2 released> as output data of the main task.