Part processes

Part processes can be used as grouping elements for activities. This allows parts of processes to be logically structured and at the same time certain settings to be maintained at an intermediate level to avoid redundancies in the activities.
A special feature of part processes is that the activities contained in them can be processed either serially or in parallel and an early termination of the part process can be set up.

Basic data

The following settings are maintained in the basic data:

Processing Mode and Early Termination
Status management
Object list status management
Various settings that can be inherited (e.g. priority)

Parallel subprocesses - synchronizing the relationship between subprocess threshold, status threshold and threshold.

In principle, the target status is determined on the basis of a threshold that is independent of the subprocess control. This makes it possible to define separately the circumstances under which the subprocess should be terminated prematurely and how the target status of the subprocess should be determined. In this case, the threshold for the status refers exclusively to the completed activities. If the status of the sub-process is to be derived from the % threshold of the sub-process itself, this can be achieved using the "Synchronize threshold" option, which always determines the status from the % threshold of the control as well as the mode.

The difference between "Consider all statuses" and "Consider all statuses, optimistic" lies in the determination of the target status in borderline cases. If the option "Consider all statuses" is set, the subprocess is terminated when the number of rejected activities has reached the threshold, with "Consider all statuses, optimistic" the number of rejected activities must exceed the threshold.
By example: If the threshold is set to 50% and the subprocess has two activities, the processing of the subprocess will be aborted if the mode is set to "Consider all statuses" and one activity is rejected. If the mode is set to "Consider all statuses, optimistic", the subprocess will not be aborted because a rejected activity does not exceed the threshold of 50% - that is, the number of positively completed activities can still reach the threshold of 50%.

Use the status settings (Status setting and % threshold) if you want to determine the status of the sub-process independently of the sub-process completion status.

Using the status threshold will not cause the subprocess to terminate prematurely.

Object List

The functionality and the distribution of the objects is described in Object List of the Process.

Person responsible

Those responsible for part processes have special rights to make changes to running part processes. Further information can be found in the user manual of ProProcess. The persons responsible for the part process are determined (via existing formulas, if applicable) and saved at the start of the part process .
The maintenance of the responsible persons is described in Members.

Dates

The maintenance and function of appointments is described in Dates .

Notifications

The maintenance and functionality of the notifications is described in Notifications .

Activities

Any number of activities can be created for a process. For serial sub-processes the order of the activities can be changed by Drag'n'Drop.-

Container

The containers are described in Containers and Items . The most important containers and items are described below:

Container/Item	Description

Container/Item	Description
HEADER	Header data
ITERATION	Number of iterations
RUNTIME_STATUS	Current status at runtime
RESPONSIBLES	Responsible Person
ALL	List of all part process owners. Can be used, for example, for Members or Notifications.

In addition, various containers are available which contain information about the agents. These can be used, for example, for Notifications .

Container/Item	Description

Container/Item	Description
ALL_AGENTS	List of all agents
ALL_CURRENT_AGENTS	List of all current agents. The current agents are those who have accepted the activity or work item. This can be done explicitly or by an executed action. Activities that have already been completed no longer have a current agent. The data is suitable, for example, for informing all agents who have not yet completed their activities and who are automatically skipped when a part process is terminated prematurely.
ALL_FINISHED_AGENTS	List of all agents who have completed an activity. The status of the activity is not relevant.
ALL_COMPLETE_AGENTS	List of all agents who have completed (and not rejected) an activity. The data is used, for example, in a decision-making process to inform the other group of the outcome. If the part process is rejected, all agents who have regularly completed the activity can be informed again.
ALL_REJECT_AGENTS	Like ALL_COMPLETE_AGENTS, but agents who rejected an activity.