Workflow Templates with Branches

If you want to create workflow templates with parallel branches, you must observe the following rules:

The branch must not be between two workflow steps that process the same form scenario.

Therefore, if several workflow steps process the same form scenario, you can only insert the branch after the last of these steps.

Reason: The next workflow step with a new form scenario always accesses the last data container of the first form scenario. If you insert a branch for the first form scenario before the last workflow step, the content of the last data container of the first form scenario depends on how far the process has progressed. The system then uses any of the first form scenario’s data containers. The data that is processed in the new form scenario is therefore not current.

The workflow template can only immediately begin with a branch if you do not use the same form scenario that is used in the start application in any of the workflow steps.

The start application is located outside the workflow template. Therefore, you do not see the initial step when editing the workflow template. However, the system processes the initial step in exactly the same way as the actual workflow steps. If you insert a branch directly after the initial step and use the same form scenario that you used in the initial step in one of the workflow steps, the same situation that is described in the first rule occurs.

Form scenarios that are processed in parallel branches of a workflow template are not allowed to access the same data.

This means, for example, that if you provide a field from a particular infotype in a form scenario for editing, you cannot provide this field in a second form scenario that you are using in a parallel branch of the same workflow template either for processing or displaying.

Reason: If two processors are processing the same field simultaneously, the system cannot evaluate whose changes are valid. If a processor is processing a field and a second processor displays the field at the same time, it is possible that the second processor will see obsolete information.

Workflow Templates with Loops

If you want to create workflow templates with loops, you must fulfill the following conditions:

Loops can occur in a workflow template in the following cases:

A processor has a query for a previous processor and therefore sends the form back to that processor.

A processor does not approve a request. The form is thus sent back to the original processor for further processing.

In the workflow template, the processing status PROCSTATE is displayed in the workflow step container using the BACK value for a query and the REJECTED value for a rejection.

After a processing status of BACK or REJECTED is set in a workflow step, the following applies:

If the following workflow step is an interactive step that has a form scenario assigned to it that has already been processed once, the form is displayed to the processor in the same way as it was originally sent. If the content of the form fields being processed in this step has been changed in other process steps, the changed data is displayed.

All following form scenarios and form scenario steps are initialized again. This means that the processor sees them as if they have never been processed before. Comments and attachments are retained however.

Reinitialization means in this case that the default values for the form are recalculated and field values from other form scenarios are transferred again if necessary. Entries that a processor has undertaken in a form scenario that is to be reinitialized are lost when the reinitialization occurs.

If a form scenario or form scenario step that has not yet been processed follows a step with a processing status of BACK or REJECTED, it is initialized as usual.

This logic has no influence on steps that do not change the content of form data containers, such as the sending of an e-mail.

Between triggering a loop and the next interactive step, you must not use any standard tasks that can change the data container (for example, the standard task TS17900108 for saving in the background). The use of such standard tasks can lead to errors during reinitialization.

Workflow Templates with Branches

Permitted Branch

The figure below shows an example of a workflow template with a branch that is permitted:

Branches That Are Not Permitted

The figures below show examples of workflow templates with branches that are not permitted. In both cases, the branches are not possible because it is not clearly defined which data container the system must use to process workflow step 2 a (Example 1) or 1 a (Example 2). When processing the B1 data container, the system can use either the A1 data container or the A2 data container, depending on whether workflow step 2 b (Example 1) or 1 b (Example 2) has already been executed or not.

Workflow Templates with Loops

Permitted Loops

Permitted Loop – Example 1

In this example, form scenario B is sent back to processor 1 after being rejected by processor 2. Processor 1 receives form scenario A in the form in which it was originally sent. Form scenario B belonging to processor 2 is then reinitialized.

In this example, form scenario B is sent back to processor 1 after being rejected by processor 2. Before processor 1 receives form scenario A again for processing, an e-mail is sent. After this, processor 1 receives form scenario A in the form in which it was originally sent. Form scenario B belonging to processor 2 is then reinitialized.

Loop That Is Not Permitted

In this example, form scenario B is sent back to processor 1 after being rejected by processor 2. Before processing the form again however, processor 1 processes form scenario C. Form scenario A is therefore reinitialized by processor 1.